Well, it sounds like you need an addon maker of some sort.
toggle quoted messageShow quoted text
As part of a project I do with games I run npm, so nodejs.
Loading nodejs current will usually load the latest npm.
Running their install script will load the latest visual studio toolset and sdks, pluss the latest pythion x86-64, right now thats 3.9. something.
Obviously you would need something completely different.
I've not mucked about with things, but I am pritty sure if I really think really hard I can probably batch some of the steps into a script.
I will have to fiddle about and see.
Thing is I really don't want to screw up my instalations I run with my node testing projects.
On 23/12/2020 11:11 pm, Tyler Spivey wrote:
1. Lacking docs. With JAWS or Window-Eyes, There is nice documentation for everything you can do with them.
There's a developer guide, but I don't think it goes into enough detail, and wouldn't even know it existed except looking in the NVDA source or this list.
2. Starting an addon is a lot of work. My workflow on a new machine is something like:
Get python, scons, git, and clone the addon template.
Go through the readme and install more dependencies (gettext) and copy out the bits I need for a new addon into a new directory (doesn't have to be in git yet).
Now edit build_vars.py to set the addon name, version and summary.
mkdir the right directories and put my code in.
Every time I want to test, I run scons, then run the addon file (though I think there's scons install now). Answer yes multiple times (this number varies depending on whether my addon is installed or not).
Wait multiple seconds for NVDA to restart (though turning off the sounds can speed it up a bit).
Now there's a hidden catch here. If my addon breaks, I'm not going to know unless I know I need the development version of NVDA.
The release versions don't play the error sound, so I'm going to want to get a snapshot which might be running newer code.
So where do I get a snapshot? They're not mensioned in the dev guide, or on the NV Access website. But Google turns them up.
The only things in here are alphas and betas. It seems there's no way to get a development version of the stable build, when all I want is to know I have an error.
Other screen readers don't have this problem.
I install the snapshot, and start testing my addon. The scons, install, restart cycle gets really annoying after a while, and I have to put up with error sounds which can't be disabled or go back to stable.
The common argument is that the developers want to hear about errors, and a lot of them are harmless.
3. If I want my addon to show up on the addons site, I have to go through the review process.
This involves posting to this list and waiting, where someone might review my addon.
On 12/22/2020 9:40 PM, Jamal Mazrui wrote:
I write this message in an attempt to provoke both thoughts and solutions. If I am attacked as a result, it is misplaced. For years, I have wanted NVDA to succeed in 3rd party extensions more than any previous screen reader. Its open source nature made me hopeful, but for whatever reasons, it has under-performed in this area so far.
As background, I have probably written and shared more JAWS scripts than anyone after accounting for Freedom Scientific, Doug Lee, and Brian Hartgen. I have bonafides on this issue.
I also developed more Window-Eyes apps/scripts than anyone after GW Micro.
I love the open source nature of NVDA; its use of one of the most popular programming languages today, having a wealth of community packages to do almost anything; and the folks on this list who help one another in enabling the screen reader to do more.
When I visit the official add-ons page, however, I am struck by a couple of things. There are not nearly the number of extensions that I would expect for a screen reader that has had an API for several years. The sophistication of the packages that do exist, moreover, are usually quite limited.
Again, my purpose is not to insult NVDA core developers, extension developers, or satisfied users. I have no interest in doing so. It would be easier just to say nothing while carrying these observations and not finding evidence to change them.
There are probably multiple explanations for this situation. I will propose just one at this time. The complexity for creating an extension, whether app-specific or global, is too high. Partly, this is because of the amount and sophistication of the code required. Partly it is because of the lack of developer documentation, including tutorials, that keep pace with the screen reader.
I hope this message is taken in the spirit in which it is intended. Why are the quantity and sophistication of NVDA extensions not substantially greater today? What can be done to fundamentally change this pattern?