Hmmm brian, well the only way to handle this is to probably make a virtual machine with vmware and or virtualbox.
toggle quoted messageShow quoted text
The biggest issue with this is you need a system and enough space.
I don't have that sort of space to keep a vm running and after my experiences with vmware non support and vmware 16 and the non updating of the enhanced keyboard causing strife, vmware is out a here!
Even when I did get a vm of win10 running to do the test it stuttered a lot and I have a system designed for virtualised hardware and the power to handle a lot of stuff.
So maybe another computer to handle programming nvda.
Then again, who knows.
Not everyone can afford the cash for a new system or have the space.
I have enough space for a computer, and maybe 1 more, I may have the cash to but thats not everyone.
The only way I could see this happening is if we can run all this in wsl or be able to boot linux from a usb stick and safely program like that leaving the core system alone.
On 24/12/2020 2:16 am, Brian's Mail list account via groups.io wrote:
You almost want a kind of virtual add on test environment that you don't have to do all the complex stuff every single time on and then when its more stable then you can run the generated code for real to find any straggling bugs. No idea if that would even be possible, but I do remember ideas like this in other languages.
Sent via blueyonder.
Please address personal E-mail to:-
firstname.lastname@example.org, putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message ----- From: "Tyler Spivey" <email@example.com>
Sent: Wednesday, December 23, 2020 10:11 AM
Subject: Re: [nvda-addons] Please do not attack this messenger. Why have NVDA add-ons not done better?
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
2. Starting an addon is a lot of work. My workflow on a new machine is
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?