Please do not attack this messenger. Why have NVDA add-ons not done better?


Jamal Mazrui <jamal@...>
 

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?


Jamal


 

Jamal the answer is because it doesn't need to.

Jaws needs scripts for just about everything to work.

Without scripts jaws will not work because of what it is it needs script like win98 needs drivers and thats all it is.

Nvda needs scripts or addons for a few spaciffic apps and or features.

Some are added to core and others.

Point is a lot of stuff is app spaciffic.

There are synths to.

There are not that many for features but no one has really been concerned.

Unlike jaws nvda doesn't need per say scripts to work properly.

I am not sure how jaws is done but in nvda's case since its built on python its itself a script.

In total I have at least 20 addons.

Most of these are to make apps work better.

They are probably not needed or necessary.

Not even win10 apps is really needed for basic functions.

For the rest of the features I have here, I am sure I could do without the extra 7 features I have installed but choose to.

On systems I administrate I have few of those.

Out of all the features I have, 3 of those like ifinterpriters, or japanese game translater are for spaciffic nonstandard tasks.

I don't really need the documentation addon but its nice, and you really only need addon updater if you need to update addons.

Cutting out vlc, win10 apps, the updater the symbols and emoticons addons which have some use, bar vlc, I don't need anything, however most of my addons are for a spaciffic function or program.

There are not as many addons because nvda doesn't need much.

Synths, extra features, well we have a music maker somewhere, weather and a few other things but really a screen reader should just be a screen reader.

You don't need audio themes, fancy ocr or anything even though nvda natively supports ocr.

Nvda is designed for everyone including those in countries without fast net access.

Nvda is not jaws.

But if nvda was jaws, then you would need scripts for everything else it wouldn't work.

So in jaws, if I delete all the scripts, its not even going to run.

Nvda can run without anything if it wants to.

There are no special configurations though there are profiles you can add, etc.

And to be honest there aren't many features I'd like to see added.

An extention store where you can get things internally.

The guy that did blind extra had the right idea almost, but only in concept.

It should be possible to buy synths and extras internally but thats just me being me.

I don't use spaciffic synths for nvda because I want to use my synths for everything else to.

Also I really don't want something to stop because my synth stops working.

Espeak works fine and I have sapi if I really need the quality.

Nvda isn't going to be for everything and everyone.

Its target is basic office, a few extra apps, and web serfing.

If you need anything more advanced than that then you get jaws because thats what you do.

Nvda is never going to be jaws and thats good as we don't want bloated software.

Jaws will bee needed for stuff nvda doesn't do.

But for the general office user, ie word and some excell, zoom, skype, teamtalk, some email and web especially with the interfaces a lot of modern apps have for most cases its going to work just fine.

Especially for the home and even small business user.

Get bigger than that, then jaws is your baby,  because nvda is not designed for all that its a general purpose system and its good for the majority of users.

On 23/12/2020 6: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?


Jamal





Dickson Tan
 

Hi Jamal,


I've only written a single add-on before, but I program professionally.


I agree with the points you raised especially about how documentation is severely lacking, especially for someone without experience with the windows API (e.g, dealing with window handles etc). Resources are also scattered across multiple places. Often, the advice I received was to look through the source code of other add-ons to try to learn from there.


I've been meaning to look into improving the accessibility of Unigram, which uses UIA. I'd love to help out if there's work that is being done to write better tutorials etc.


Cheers,

Dickson

On 23/12/2020 1: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?


Jamal





Reef Turner
 

Hi Jamal,

I think this is a good conversation to have, we may be able to identify small ways that the ecosystem can be improved immediately, or a road map for longer term goals. I'll be interested to hear the different opinions that add-on authors have.

Jamal, could you expand on your own experience? What has motivated you to write add-ons / extensions / scripts for JAWS and Window-Eyes?

Reef Turner
Software Developer - NV Access


On Wed, 23 Dec 2020 at 13:40, Jamal Mazrui <jamal@...> 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?


Jamal







Héctor Javier Benítez Corredera
 

Good morning. It is very simple.

I think I have installed 4 or 5 official accessories.

Unofficial I have a lot, you have to wonder why the developers do not even want to appear here.

A month ago I submitted an add-on for review which only Paul replied that it overlapped with an option in his NVDAExtensionGlobal add-on to which I replied that it did not.

Yesterday, the Jose Manuel Proxy add-on was also presented which has not even received a comment, seeming to me to be an add-on that even solves an issue that has been open for years in the core of NVDA.

Well my opinion is simple, we behave like children in the school yard by developers of this community and that in the long run comes in prejudice of the whole community.

It seems to me that it is not very serious to screen who can have an official complement and who can't. That in the end puts the developers off.

And I'm very sorry for that, but I'm leaving my add-ons to the Hispanic community and if someone likes them, I don't care if they are official or not, but I'm very sorry and I'm not going to allow people in this community to look down on me.

I think that this approach could also be added to the list of why NVDA is not progressing more and better and it is really a shame that it is so difficult to share knowledge through nets that in the end it is a detriment.
Greetings

El 23/12/2020 a las 7:33, Reef Turner escribió:
Hi Jamal,

I think this is a good conversation to have, we may be able to identify small ways that the ecosystem can be improved immediately, or a road map for longer term goals. I'll be interested to hear the different opinions that add-on authors have.

Jamal, could you expand on your own experience? What has motivated you to write add-ons / extensions / scripts for JAWS and Window-Eyes?

Reef Turner
Software Developer - NV Access

On Wed, 23 Dec 2020 at 13:40, Jamal Mazrui <jamal@...> 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?


Jamal







 

Well if there is a lack and you can see how to fix it then do so thats the nature of opensource.

For myself, and for what I use I don't mind how nvda is now.

However ever since I left an active mainstream life as far as business goes, my work consists of chrome and chromium, an older version of waterfox which behaves itself, and internet explorer, and thunderbird.

I dabble with some office programs mainly outlook and word, a bit of dropbox, and zoom, teamtalk and skype, and some winamp and github desktop.

Bar some npm and node stuff, I rarely really do much more than game or enter jarte.

Mostly its web and email these days with the occasional. voice conference.

This year alone I have increased my zoom time as well as web testing time.

I spend most of my time in serveys and email.

I test dolphin readers, but not jaws.

Then again, I'm not going to say no if fs or visparo gets me to test mr bloated advanced reader.

All testing for now is for nothing at least from the screen reader industry, except that I do get a free program so there

's that I guess.

On 23/12/2020 7:28 pm, Dickson Tan wrote:
Hi Jamal,


I've only written a single add-on before, but I program professionally.


I agree with the points you raised especially about how documentation is severely lacking, especially for someone without experience with the windows API (e.g, dealing with window handles etc). Resources are also scattered across multiple places. Often, the advice I received was to look through the source code of other add-ons to try to learn from there.


I've been meaning to look into improving the accessibility of Unigram, which uses UIA. I'd love to help out if there's work that is being done to write better tutorials etc.


Cheers,

Dickson


On 23/12/2020 1: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?


Jamal








.


 

To be honest, the current infrastructure for the addons system sucks.

I think its being updated though.

To submit to community, it needs to be done manually at some point.

I really think there should be a way to have repositories of things official and not, I mean linux does it.

We did sadly have blindextra and those at the top want to keep things secure.

Saying that, there are more unofficial and perfectly legal addons out there which are not on the main system.

There are also alegal ones, older ones, etc.

I am not sure how to handle this but there is actually more out there than is on the main page.



On 23/12/2020 8:19 pm, Héctor Javier Benítez Corredera wrote:

Good morning. It is very simple.

I think I have installed 4 or 5 official accessories.

Unofficial I have a lot, you have to wonder why the developers do not even want to appear here.

A month ago I submitted an add-on for review which only Paul replied that it overlapped with an option in his NVDAExtensionGlobal add-on to which I replied that it did not.

Yesterday, the Jose Manuel Proxy add-on was also presented which has not even received a comment, seeming to me to be an add-on that even solves an issue that has been open for years in the core of NVDA.

Well my opinion is simple, we behave like children in the school yard by developers of this community and that in the long run comes in prejudice of the whole community.

It seems to me that it is not very serious to screen who can have an official complement and who can't. That in the end puts the developers off.

And I'm very sorry for that, but I'm leaving my add-ons to the Hispanic community and if someone likes them, I don't care if they are official or not, but I'm very sorry and I'm not going to allow people in this community to look down on me.

I think that this approach could also be added to the list of why NVDA is not progressing more and better and it is really a shame that it is so difficult to share knowledge through nets that in the end it is a detriment.
Greetings

El 23/12/2020 a las 7:33, Reef Turner escribió:
Hi Jamal,

I think this is a good conversation to have, we may be able to identify small ways that the ecosystem can be improved immediately, or a road map for longer term goals. I'll be interested to hear the different opinions that add-on authors have.

Jamal, could you expand on your own experience? What has motivated you to write add-ons / extensions / scripts for JAWS and Window-Eyes?

Reef Turner
Software Developer - NV Access

On Wed, 23 Dec 2020 at 13:40, Jamal Mazrui <jamal@...> 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?


Jamal







Meisam Amini <meisamamini21@...>
 

I'm a beginner and just learning to write add-ons. From my point of
view the biggest problem is the lack of documentation and tutorials.
And the development for NVDA not being very non-professional
programmer friendly.

I dabbled in writing scripts for JAWS a bit some time ago, and a very
pleasant part of it was a complete tutorial and a single .chm
reference file. The file included categorized documentation for every
single function used in scripting for JAWS.

Almost every tech savvy person can write a simple script for JAWS
after learning how to, but only a relatively advanced Python
programmer can write add-ons for NVDA.

I love NVDA and hope it grows more and more, for that I think the
community needs to put some effort on creating more and better
documentation and tutorials.

Also, I guess there are a lot of add-ons that haven't been posted on
the official page.

On 12/23/20, Shaun Everiss <sm.everiss@gmail.com> wrote:
To be honest, the current infrastructure for the addons system sucks.

I think its being updated though.

To submit to community, it needs to be done manually at some point.

I really think there should be a way to have repositories of things
official and not, I mean linux does it.

We did sadly have blindextra and those at the top want to keep things
secure.

Saying that, there are more unofficial and perfectly legal addons out
there which are not on the main system.

There are also alegal ones, older ones, etc.

I am not sure how to handle this but there is actually more out there
than is on the main page.



On 23/12/2020 8:19 pm, Héctor Javier Benítez Corredera wrote:

Good morning. It is very simple.

I think I have installed 4 or 5 official accessories.

Unofficial I have a lot, you have to wonder why the developers do not
even want to appear here.

A month ago I submitted an add-on for review which only Paul replied
that it overlapped with an option in his NVDAExtensionGlobal add-on to
which I replied that it did not.

Yesterday, the Jose Manuel Proxy add-on was also presented which has
not even received a comment, seeming to me to be an add-on that even
solves an issue that has been open for years in the core of NVDA.

Well my opinion is simple, we behave like children in the school yard
by developers of this community and that in the long run comes in
prejudice of the whole community.

It seems to me that it is not very serious to screen who can have an
official complement and who can't. That in the end puts the developers
off.

And I'm very sorry for that, but I'm leaving my add-ons to the
Hispanic community and if someone likes them, I don't care if they are
official or not, but I'm very sorry and I'm not going to allow people
in this community to look down on me.

I think that this approach could also be added to the list of why NVDA
is not progressing more and better and it is really a shame that it is
so difficult to share knowledge through nets that in the end it is a
detriment.
Greetings

El 23/12/2020 a las 7:33, Reef Turner escribió:
Hi Jamal,

I think this is a good conversation to have, we may be able to
identify small ways that the ecosystem can be improved immediately,
or a road map for longer term goals. I'll be interested to hear the
different opinions that add-on authors have.

Jamal, could you expand on your own experience? What has motivated
you to write add-ons / extensions / scripts for JAWS and Window-Eyes?

Reef Turner
Software Developer - NV Access

On Wed, 23 Dec 2020 at 13:40, Jamal Mazrui <jamal@empowermentzone.com
<mailto:jamal@empowermentzone.com>> 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?


Jamal










Noelia Ruiz
 

Hello, this is feedback from my part, as a person who wrote JAWS
scripts too. In fact, I think that JAWS scripts documentation was much
more complete and well structured than NVDA's developer guides. But I
feel that Python is a wider language and we can use lots of external
libraries, so, by nature, NVDA's documentation will not be so
complete.
In the other hand, we can see a wider diversity of examples about
NVDA's add-ons than JAWS scripts, and personally my approach to write
some NVDA add-ons was:
1. Read the NV Access developer guide and part of NVDA's code.
2. Write plugins and see NVDA's log.

This means that imo we cannot expect the same approach for developing
JAWS scripts and NVDA add-ons, considering that JAWS scripts language
is more limited (not open source, so no extensible by the community in
the same way that Python). With JAWS scripts, we can read structured
documentation which can explain many features of that language.
About add-ons posted on the official website, I created plugins posted
on the website, but not alll of them received a reply by reviewers. I
think that maintaining a website requires a lot of work by translators
and reviewers, and that we cannot expect that our work will result
interesting or useful to the community now or in the future.
I think, honestly, that when Mesar, the person who hosted the website
in the first place, first creator of the add-ons guidelines and the
review process, was active, we have a better coordination. Later it
was more difficult and some people made efforzs to maintain the
website. Also, Joseph wrote a developer guide and I wrote several
small articles in the wiki, among other tutorials that I may don't
know.
A different approach would be to create a system where everyone could
post add-ons recognized by NVDA without needing to be reviewed.
But I don't think we have to believe that it's a right to have our
add-ons posted on the website, sincerely. One of the aspects
considered in the review guidelines was the possibility of merging
several add-ons. What happens if some of them have very similar
features? Is this good for the website?
Cheers

2020-12-23 8:51 GMT+01:00, Meisam Amini <meisamamini21@gmail.com>:

I'm a beginner and just learning to write add-ons. From my point of
view the biggest problem is the lack of documentation and tutorials.
And the development for NVDA not being very non-professional
programmer friendly.

I dabbled in writing scripts for JAWS a bit some time ago, and a very
pleasant part of it was a complete tutorial and a single .chm
reference file. The file included categorized documentation for every
single function used in scripting for JAWS.

Almost every tech savvy person can write a simple script for JAWS
after learning how to, but only a relatively advanced Python
programmer can write add-ons for NVDA.

I love NVDA and hope it grows more and more, for that I think the
community needs to put some effort on creating more and better
documentation and tutorials.

Also, I guess there are a lot of add-ons that haven't been posted on
the official page.

On 12/23/20, Shaun Everiss <sm.everiss@gmail.com> wrote:
To be honest, the current infrastructure for the addons system sucks.

I think its being updated though.

To submit to community, it needs to be done manually at some point.

I really think there should be a way to have repositories of things
official and not, I mean linux does it.

We did sadly have blindextra and those at the top want to keep things
secure.

Saying that, there are more unofficial and perfectly legal addons out
there which are not on the main system.

There are also alegal ones, older ones, etc.

I am not sure how to handle this but there is actually more out there
than is on the main page.



On 23/12/2020 8:19 pm, Héctor Javier Benítez Corredera wrote:

Good morning. It is very simple.

I think I have installed 4 or 5 official accessories.

Unofficial I have a lot, you have to wonder why the developers do not
even want to appear here.

A month ago I submitted an add-on for review which only Paul replied
that it overlapped with an option in his NVDAExtensionGlobal add-on to
which I replied that it did not.

Yesterday, the Jose Manuel Proxy add-on was also presented which has
not even received a comment, seeming to me to be an add-on that even
solves an issue that has been open for years in the core of NVDA.

Well my opinion is simple, we behave like children in the school yard
by developers of this community and that in the long run comes in
prejudice of the whole community.

It seems to me that it is not very serious to screen who can have an
official complement and who can't. That in the end puts the developers
off.

And I'm very sorry for that, but I'm leaving my add-ons to the
Hispanic community and if someone likes them, I don't care if they are
official or not, but I'm very sorry and I'm not going to allow people
in this community to look down on me.

I think that this approach could also be added to the list of why NVDA
is not progressing more and better and it is really a shame that it is
so difficult to share knowledge through nets that in the end it is a
detriment.
Greetings

El 23/12/2020 a las 7:33, Reef Turner escribió:
Hi Jamal,

I think this is a good conversation to have, we may be able to
identify small ways that the ecosystem can be improved immediately,
or a road map for longer term goals. I'll be interested to hear the
different opinions that add-on authors have.

Jamal, could you expand on your own experience? What has motivated
you to write add-ons / extensions / scripts for JAWS and Window-Eyes?

Reef Turner
Software Developer - NV Access

On Wed, 23 Dec 2020 at 13:40, Jamal Mazrui <jamal@empowermentzone.com
<mailto:jamal@empowermentzone.com>> 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?


Jamal














Tyler Spivey
 

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?
Jamal


 

Thats true.

Another major issue is securing addons, there is a reason to not have everything in community, and a reason to watch things a bit.

Python can do a few things jaws scripting can't, you can run programs within programs.

Blindextra was a bad example of this and no one really does that to much though some stuff has done stuff like running external programs in the past though its not encouraged.

Point is, we need to be sure we have control so keeping things small does help.

In reality, there is no reason someone couldn't do something like blindextra again, sure we are smarter but it still could happen.

We really don't have much more protection except for our heads if someone abused the system.

As for docs and such this is a work in progress.

On 23/12/2020 10:56 pm, Noelia Ruiz wrote:
Hello, this is feedback from my part, as a person who wrote JAWS
scripts too. In fact, I think that JAWS scripts documentation was much
more complete and well structured than NVDA's developer guides. But I
feel that Python is a wider language and we can use lots of external
libraries, so, by nature, NVDA's documentation will not be so
complete.
In the other hand, we can see a wider diversity of examples about
NVDA's add-ons than JAWS scripts, and personally my approach to write
some NVDA add-ons was:
1. Read the NV Access developer guide and part of NVDA's code.
2. Write plugins and see NVDA's log.

This means that imo we cannot expect the same approach for developing
JAWS scripts and NVDA add-ons, considering that JAWS scripts language
is more limited (not open source, so no extensible by the community in
the same way that Python). With JAWS scripts, we can read structured
documentation which can explain many features of that language.
About add-ons posted on the official website, I created plugins posted
on the website, but not alll of them received a reply by reviewers. I
think that maintaining a website requires a lot of work by translators
and reviewers, and that we cannot expect that our work will result
interesting or useful to the community now or in the future.
I think, honestly, that when Mesar, the person who hosted the website
in the first place, first creator of the add-ons guidelines and the
review process, was active, we have a better coordination. Later it
was more difficult and some people made efforzs to maintain the
website. Also, Joseph wrote a developer guide and I wrote several
small articles in the wiki, among other tutorials that I may don't
know.
A different approach would be to create a system where everyone could
post add-ons recognized by NVDA without needing to be reviewed.
But I don't think we have to believe that it's a right to have our
add-ons posted on the website, sincerely. One of the aspects
considered in the review guidelines was the possibility of merging
several add-ons. What happens if some of them have very similar
features? Is this good for the website?
Cheers

2020-12-23 8:51 GMT+01:00, Meisam Amini <meisamamini21@gmail.com>:
I'm a beginner and just learning to write add-ons. From my point of
view the biggest problem is the lack of documentation and tutorials.
And the development for NVDA not being very non-professional
programmer friendly.

I dabbled in writing scripts for JAWS a bit some time ago, and a very
pleasant part of it was a complete tutorial and a single .chm
reference file. The file included categorized documentation for every
single function used in scripting for JAWS.

Almost every tech savvy person can write a simple script for JAWS
after learning how to, but only a relatively advanced Python
programmer can write add-ons for NVDA.

I love NVDA and hope it grows more and more, for that I think the
community needs to put some effort on creating more and better
documentation and tutorials.

Also, I guess there are a lot of add-ons that haven't been posted on
the official page.

On 12/23/20, Shaun Everiss <sm.everiss@gmail.com> wrote:
To be honest, the current infrastructure for the addons system sucks.

I think its being updated though.

To submit to community, it needs to be done manually at some point.

I really think there should be a way to have repositories of things
official and not, I mean linux does it.

We did sadly have blindextra and those at the top want to keep things
secure.

Saying that, there are more unofficial and perfectly legal addons out
there which are not on the main system.

There are also alegal ones, older ones, etc.

I am not sure how to handle this but there is actually more out there
than is on the main page.



On 23/12/2020 8:19 pm, Héctor Javier Benítez Corredera wrote:
Good morning. It is very simple.

I think I have installed 4 or 5 official accessories.

Unofficial I have a lot, you have to wonder why the developers do not
even want to appear here.

A month ago I submitted an add-on for review which only Paul replied
that it overlapped with an option in his NVDAExtensionGlobal add-on to
which I replied that it did not.

Yesterday, the Jose Manuel Proxy add-on was also presented which has
not even received a comment, seeming to me to be an add-on that even
solves an issue that has been open for years in the core of NVDA.

Well my opinion is simple, we behave like children in the school yard
by developers of this community and that in the long run comes in
prejudice of the whole community.

It seems to me that it is not very serious to screen who can have an
official complement and who can't. That in the end puts the developers
off.

And I'm very sorry for that, but I'm leaving my add-ons to the
Hispanic community and if someone likes them, I don't care if they are
official or not, but I'm very sorry and I'm not going to allow people
in this community to look down on me.

I think that this approach could also be added to the list of why NVDA
is not progressing more and better and it is really a shame that it is
so difficult to share knowledge through nets that in the end it is a
detriment.
Greetings

El 23/12/2020 a las 7:33, Reef Turner escribió:
Hi Jamal,

I think this is a good conversation to have, we may be able to
identify small ways that the ecosystem can be improved immediately,
or a road map for longer term goals. I'll be interested to hear the
different opinions that add-on authors have.

Jamal, could you expand on your own experience? What has motivated
you to write add-ons / extensions / scripts for JAWS and Window-Eyes?

Reef Turner
Software Developer - NV Access

On Wed, 23 Dec 2020 at 13:40, Jamal Mazrui <jamal@empowermentzone.com
<mailto:jamal@empowermentzone.com>> 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?


Jamal













 

Well, it sounds like you need an addon maker of some sort.

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?


Jamal








Christo de Klerk
 

Hi Jamal

I have had great experiences over many years using your programs and Window-Eyes apps and I learnt a lot from your code. I have a lot of respect for your programming skills.

In my profession I was a programmer for many years in various languages. In Window-Eyes world I developed a few apps. I have created a few NVDA add-ons and quite a few AutoHotkey utilities for personal use.

I agree absolutely with the points you made. The lack of proper documentation is a big showstopper. Where the documentation really fails, is in describing which procedures and functions in the NVDA core are exposed for use in add-ons and how to use them. It really is not good enough to just say, "Go and look at the source code". That is just too cumbersome and time-consuming. The Window-Eyes documentation was really excellent.

I agree with Tyler that the whole add-on development infrastructure is just way too clunky. Again in Window-Eyes world much of it was done/automated for the developer.

I do not agree with Shaun that there was much more app development around Jaws and Window-Eyes because they needed it. I don't really know Jaws, but I knew Window-Eyes intimately and I know that there were many apps providing functionality that went way beyond what is currently available for NVDA.

Of course, in the case of Jaws and Window-Eyes staff were employed who developed good documentation and infrastructure as part of their salaried jobs, whereas in the case of NVDA, volunteers give their time and expertise, so it is understandable if documentation and development infrastructure might not be at the same level.

So, in short, I think that NVDA add-on development would only really take off if or when it becomes easier to learn and do things, if it becomes less of an effort to develop add-ons.  Kind regards

Christo


On 2020/12/23 07:40am, 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?


Jamal








Brian's Mail list account
 

I don't think if what you perceive might seem that way to you, that this is in any way intentional at all. It seems, as an observer for many years that the various programmers here are add on writers only in their spare time, and that their paid work often curtails the involvement they can offer. As with any voluntary work, the tendency is to take on too much, with difficult choices having to be made when work gets busy in order to preserve sanity so to speak. I think I'm right in saying that a lot of Jaws scripts are not free. Instead of app modules as nvda has, Jaws has had to have scripts written and some are included, and the price reflects this, and some can be purchased while yes, some are free. The main people paying for scripts are nearly always employers or a government entity as part of provision of adjustments to enable blind people to get and retain work. This is why Jaws mostly exists I feel. Although not so much now, the open source aspect of NVDA was frowned upon by admins, now that Microsoft themselves include open source in some apps, there is little to argue about. So maybe somebody needs to set up for paid for add ons supplying to companies for their bespoke software, or something like that?
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Héctor Javier Benítez Corredera" <hebolah@gmail.com>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Wednesday, December 23, 2020 7:19 AM
Subject: Re: [nvda-addons] Please do not attack this messenger. Why have NVDA add-ons not done better?


Good morning. It is very simple.

I think I have installed 4 or 5 official accessories.

Unofficial I have a lot, you have to wonder why the developers do not
even want to appear here.

A month ago I submitted an add-on for review which only Paul replied
that it overlapped with an option in his NVDAExtensionGlobal add-on to
which I replied that it did not.

Yesterday, the Jose Manuel Proxy add-on was also presented which has not
even received a comment, seeming to me to be an add-on that even solves
an issue that has been open for years in the core of NVDA.

Well my opinion is simple, we behave like children in the school yard by
developers of this community and that in the long run comes in prejudice
of the whole community.

It seems to me that it is not very serious to screen who can have an
official complement and who can't. That in the end puts the developers off.

And I'm very sorry for that, but I'm leaving my add-ons to the Hispanic
community and if someone likes them, I don't care if they are official
or not, but I'm very sorry and I'm not going to allow people in this
community to look down on me.

I think that this approach could also be added to the list of why NVDA
is not progressing more and better and it is really a shame that it is
so difficult to share knowledge through nets that in the end it is a
detriment.
Greetings

El 23/12/2020 a las 7:33, Reef Turner escribió:
Hi Jamal,

I think this is a good conversation to have, we may be able to
identify small ways that the ecosystem can be improved immediately, or
a road map for longer term goals. I'll be interested to hear the
different opinions that add-on authors have.

Jamal, could you expand on your own experience? What has motivated you
to write add-ons / extensions / scripts for JAWS and Window-Eyes?

Reef Turner
Software Developer - NV Access

On Wed, 23 Dec 2020 at 13:40, Jamal Mazrui <jamal@empowermentzone.com
<mailto:jamal@empowermentzone.com>> 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?


Jamal










Brian's Mail list account
 

I agree there needs to be somebody out there who can de mystify all the jargon that the experts talk about on the developer list and explain exactly what is going on and the underlying reasons etc.

Back in the day of home computers you could buy in the high street and write software on directly, there were authors who were very good at that sort of de mystification, but now everything has returned to the close black box way for consumers.
I mean I find merely understanding dos batch files seems to astound otherwise intelligent people!
They never realised that writing software did not need a huge brain and lots of qualifications.
I don't want to hi jack this thread, I was merely demonstrating the kind of problems we now have with the historical context we lie in now.
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Meisam Amini" <meisamamini21@gmail.com>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Wednesday, December 23, 2020 7:51 AM
Subject: Re: [nvda-addons] Please do not attack this messenger. Why have NVDA add-ons not done better?


I'm a beginner and just learning to write add-ons. From my point of
view the biggest problem is the lack of documentation and tutorials.
And the development for NVDA not being very non-professional
programmer friendly.

I dabbled in writing scripts for JAWS a bit some time ago, and a very
pleasant part of it was a complete tutorial and a single .chm
reference file. The file included categorized documentation for every
single function used in scripting for JAWS.

Almost every tech savvy person can write a simple script for JAWS
after learning how to, but only a relatively advanced Python
programmer can write add-ons for NVDA.

I love NVDA and hope it grows more and more, for that I think the
community needs to put some effort on creating more and better
documentation and tutorials.

Also, I guess there are a lot of add-ons that haven't been posted on
the official page.

On 12/23/20, Shaun Everiss <sm.everiss@gmail.com> wrote:
To be honest, the current infrastructure for the addons system sucks.

I think its being updated though.

To submit to community, it needs to be done manually at some point.

I really think there should be a way to have repositories of things
official and not, I mean linux does it.

We did sadly have blindextra and those at the top want to keep things
secure.

Saying that, there are more unofficial and perfectly legal addons out
there which are not on the main system.

There are also alegal ones, older ones, etc.

I am not sure how to handle this but there is actually more out there
than is on the main page.



On 23/12/2020 8:19 pm, Héctor Javier Benítez Corredera wrote:

Good morning. It is very simple.

I think I have installed 4 or 5 official accessories.

Unofficial I have a lot, you have to wonder why the developers do not
even want to appear here.

A month ago I submitted an add-on for review which only Paul replied
that it overlapped with an option in his NVDAExtensionGlobal add-on to
which I replied that it did not.

Yesterday, the Jose Manuel Proxy add-on was also presented which has
not even received a comment, seeming to me to be an add-on that even
solves an issue that has been open for years in the core of NVDA.

Well my opinion is simple, we behave like children in the school yard
by developers of this community and that in the long run comes in
prejudice of the whole community.

It seems to me that it is not very serious to screen who can have an
official complement and who can't. That in the end puts the developers
off.

And I'm very sorry for that, but I'm leaving my add-ons to the
Hispanic community and if someone likes them, I don't care if they are
official or not, but I'm very sorry and I'm not going to allow people
in this community to look down on me.

I think that this approach could also be added to the list of why NVDA
is not progressing more and better and it is really a shame that it is
so difficult to share knowledge through nets that in the end it is a
detriment.
Greetings

El 23/12/2020 a las 7:33, Reef Turner escribió:
Hi Jamal,

I think this is a good conversation to have, we may be able to
identify small ways that the ecosystem can be improved immediately,
or a road map for longer term goals. I'll be interested to hear the
different opinions that add-on authors have.

Jamal, could you expand on your own experience? What has motivated
you to write add-ons / extensions / scripts for JAWS and Window-Eyes?

Reef Turner
Software Developer - NV Access

On Wed, 23 Dec 2020 at 13:40, Jamal Mazrui <jamal@empowermentzone.com
<mailto:jamal@empowermentzone.com>> 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?


Jamal










Brian's Mail list account
 

It is also easy to accidentally to compromise security merely by trying to make a helpful add on. Python one assumes could easily be used to write malicious code of any type.
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Shaun Everiss" <sm.everiss@gmail.com>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Wednesday, December 23, 2020 10:40 AM
Subject: Re: [nvda-addons] Please do not attack this messenger. Why have NVDA add-ons not done better?


Thats true.

Another major issue is securing addons, there is a reason to not have everything in community, and a reason to watch things a bit.

Python can do a few things jaws scripting can't, you can run programs within programs.

Blindextra was a bad example of this and no one really does that to much though some stuff has done stuff like running external programs in the past though its not encouraged.

Point is, we need to be sure we have control so keeping things small does help.

In reality, there is no reason someone couldn't do something like blindextra again, sure we are smarter but it still could happen.

We really don't have much more protection except for our heads if someone abused the system.

As for docs and such this is a work in progress.



On 23/12/2020 10:56 pm, Noelia Ruiz wrote:
Hello, this is feedback from my part, as a person who wrote JAWS
scripts too. In fact, I think that JAWS scripts documentation was much
more complete and well structured than NVDA's developer guides. But I
feel that Python is a wider language and we can use lots of external
libraries, so, by nature, NVDA's documentation will not be so
complete.
In the other hand, we can see a wider diversity of examples about
NVDA's add-ons than JAWS scripts, and personally my approach to write
some NVDA add-ons was:
1. Read the NV Access developer guide and part of NVDA's code.
2. Write plugins and see NVDA's log.

This means that imo we cannot expect the same approach for developing
JAWS scripts and NVDA add-ons, considering that JAWS scripts language
is more limited (not open source, so no extensible by the community in
the same way that Python). With JAWS scripts, we can read structured
documentation which can explain many features of that language.
About add-ons posted on the official website, I created plugins posted
on the website, but not alll of them received a reply by reviewers. I
think that maintaining a website requires a lot of work by translators
and reviewers, and that we cannot expect that our work will result
interesting or useful to the community now or in the future.
I think, honestly, that when Mesar, the person who hosted the website
in the first place, first creator of the add-ons guidelines and the
review process, was active, we have a better coordination. Later it
was more difficult and some people made efforzs to maintain the
website. Also, Joseph wrote a developer guide and I wrote several
small articles in the wiki, among other tutorials that I may don't
know.
A different approach would be to create a system where everyone could
post add-ons recognized by NVDA without needing to be reviewed.
But I don't think we have to believe that it's a right to have our
add-ons posted on the website, sincerely. One of the aspects
considered in the review guidelines was the possibility of merging
several add-ons. What happens if some of them have very similar
features? Is this good for the website?
Cheers

2020-12-23 8:51 GMT+01:00, Meisam Amini <meisamamini21@gmail.com>:
I'm a beginner and just learning to write add-ons. From my point of
view the biggest problem is the lack of documentation and tutorials.
And the development for NVDA not being very non-professional
programmer friendly.

I dabbled in writing scripts for JAWS a bit some time ago, and a very
pleasant part of it was a complete tutorial and a single .chm
reference file. The file included categorized documentation for every
single function used in scripting for JAWS.

Almost every tech savvy person can write a simple script for JAWS
after learning how to, but only a relatively advanced Python
programmer can write add-ons for NVDA.

I love NVDA and hope it grows more and more, for that I think the
community needs to put some effort on creating more and better
documentation and tutorials.

Also, I guess there are a lot of add-ons that haven't been posted on
the official page.

On 12/23/20, Shaun Everiss <sm.everiss@gmail.com> wrote:
To be honest, the current infrastructure for the addons system sucks.

I think its being updated though.

To submit to community, it needs to be done manually at some point.

I really think there should be a way to have repositories of things
official and not, I mean linux does it.

We did sadly have blindextra and those at the top want to keep things
secure.

Saying that, there are more unofficial and perfectly legal addons out
there which are not on the main system.

There are also alegal ones, older ones, etc.

I am not sure how to handle this but there is actually more out there
than is on the main page.



On 23/12/2020 8:19 pm, Héctor Javier Benítez Corredera wrote:
Good morning. It is very simple.

I think I have installed 4 or 5 official accessories.

Unofficial I have a lot, you have to wonder why the developers do not
even want to appear here.

A month ago I submitted an add-on for review which only Paul replied
that it overlapped with an option in his NVDAExtensionGlobal add-on to
which I replied that it did not.

Yesterday, the Jose Manuel Proxy add-on was also presented which has
not even received a comment, seeming to me to be an add-on that even
solves an issue that has been open for years in the core of NVDA.

Well my opinion is simple, we behave like children in the school yard
by developers of this community and that in the long run comes in
prejudice of the whole community.

It seems to me that it is not very serious to screen who can have an
official complement and who can't. That in the end puts the developers
off.

And I'm very sorry for that, but I'm leaving my add-ons to the
Hispanic community and if someone likes them, I don't care if they are
official or not, but I'm very sorry and I'm not going to allow people
in this community to look down on me.

I think that this approach could also be added to the list of why NVDA
is not progressing more and better and it is really a shame that it is
so difficult to share knowledge through nets that in the end it is a
detriment.
Greetings

El 23/12/2020 a las 7:33, Reef Turner escribió:
Hi Jamal,

I think this is a good conversation to have, we may be able to
identify small ways that the ecosystem can be improved immediately,
or a road map for longer term goals. I'll be interested to hear the
different opinions that add-on authors have.

Jamal, could you expand on your own experience? What has motivated
you to write add-ons / extensions / scripts for JAWS and Window-Eyes?

Reef Turner
Software Developer - NV Access

On Wed, 23 Dec 2020 at 13:40, Jamal Mazrui <jamal@empowermentzone.com
<mailto:jamal@empowermentzone.com>> 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?


Jamal















Brian's Mail list account
 

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.
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Tyler Spivey" <tspivey@pcdesk.net>
To: <nvda-addons@nvda-addons.groups.io>
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
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?


Jamal






Sean <s.tolstoyevski@...>
 

While everything is fine, NVDA freezing in severe conditions drives me crazy.
Especially like when doing parallel compiles, it freezes very badly even though there is enough amount left in the CPU.
I am writing these issues to the NVDA team. It is generally not looked after because it requires very deep analysis and debugging.

I do not even want to explain the documentation.
The official plugin tutorial just described something as simple as beep and nothing else.
Scenarios are not that easy.

Currently there is no native x64 support.

Someone who wants to develop a small plugin for himself has to learn Python and OOP, moreover win32api.
Not everyone has friends who know Python and NVDA.

I don't think a language like Python can handle dynamic content in the current world.

On 23/12/2020 08:40, 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?


Jamal





Sergio Gómez <gomez.sergio.3110@...>
 

Hello Héctor!

 

That's right, your plugin is worth a lot, just like José's new plugin.

No one should look down on you for anything, because you are worth a lot. I admire you for your accessories, for example this one. It is useful to the maximum and very simple to use, no knowledge of anything is needed.

 

Cheers

 

Sergio Gomez

De: Héctor Javier Benítez Corredera
Enviado: miércoles, 23 de diciembre de 2020 8:19
Para: nvda-addons@nvda-addons.groups.io
Asunto: Re: [nvda-addons] Please do not attack this messenger. Why have NVDA add-ons not done better?

 

Good morning. It is very simple.

I think I have installed 4 or 5 official accessories.

Unofficial I have a lot, you have to wonder why the developers do not even want to appear here.

A month ago I submitted an add-on for review which only Paul replied that it overlapped with an option in his NVDAExtensionGlobal add-on to which I replied that it did not.

Yesterday, the Jose Manuel Proxy add-on was also presented which has not even received a comment, seeming to me to be an add-on that even solves an issue that has been open for years in the core of NVDA.

Well my opinion is simple, we behave like children in the school yard by developers of this community and that in the long run comes in prejudice of the whole community.

It seems to me that it is not very serious to screen who can have an official complement and who can't. That in the end puts the developers off.

And I'm very sorry for that, but I'm leaving my add-ons to the Hispanic community and if someone likes them, I don't care if they are official or not, but I'm very sorry and I'm not going to allow people in this community to look down on me.

I think that this approach could also be added to the list of why NVDA is not progressing more and better and it is really a shame that it is so difficult to share knowledge through nets that in the end it is a detriment.
Greetings

El 23/12/2020 a las 7:33, Reef Turner escribió:

Hi Jamal,

 

I think this is a good conversation to have, we may be able to identify small ways that the ecosystem can be improved immediately, or a road map for longer term goals. I'll be interested to hear the different opinions that add-on authors have.

 

Jamal, could you expand on your own experience? What has motivated you to write add-ons / extensions / scripts for JAWS and Window-Eyes?

 

Reef Turner
Software Developer - NV Access

 

On Wed, 23 Dec 2020 at 13:40, Jamal Mazrui <jamal@...> 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?


Jamal





 


James Scholes
 

I'm glad somebody is asking this question. Clearly, NVDA's use of Python is a boon for add-on writers, even those who don't already know it. Primarily that's down to the wealth of information out there about Python, which is the polar opposite of the JAWS-specific scripting language. That's especially true now that NVDA is using Python 3.

Having said that, I agree with others about the state of the documentation. There is the main developer guide, as well as community contributions. But reference material is basically non-existent. A few days ago on this list, I wrote that reading the code was easier than reading the generated developer docs, and I stand by that statement. But the reason is that the generated docs are inconsistent and not particularly navigable, making the effort to generate them a waste of time in most cases. If quote "proper" unquote documentation was provided to assist people in a deep dive, categorised in a predictable fashion, it would be a massive improvement.

What we do have, as already stated, is a huge amount of information about using Python for all sorts of tasks out there on the web. This is reflected in the large number of what I would call "utility" add-ons, which help users achieve tasks that are non-NVDA-specific like reading RSS feeds or the weather. I have nothing against such add-ons, but their existence is worth highlighting, as is the balance of questions that are raised on this mailing list.

It's extremely common for people to have queries about what may be considered common screen reader scripting tasks. Locating controls, identifying visually-indicated state, adding labels to things or adding role semantics are some examples that come to mind. It's not nearly as common for people to seek help with Python syntax, accessing web APIs, creating threads or popping up WXPython dialogs. But yet a large number of add-ons do these things. This may support assertions that when it comes to NVDA-specific tasks, people just don't know where to look for examples and meaningful help, but when it comes to non-NVDA-specific topics they are spoilt for choice.

Another issue that comes to mind is a more technical one: the need for monkey-patching. Again, Python is a big plus for add-on writers, as is the fact that an NVDA add-on basically has unlimited access to the internal state of the screen reader, at least for those parts that are also developed in Python. But this has created a situation where the sharing and boundaries of internal mechanisms are not clearly defined. The JAWS scripting language may be proprietary, but its inclusion requires well-defined interfaces to be created for scripters. That isn't a hard requirement inside NVDA, so it hasn't happened. But it does harm opportunities to do things in a future-proof way.

I'll end on a couple of final things of note:

1. I'm sure there are other aspects to add-on development which are doing more harm than good. Others have mentioned the attitudes of community reviewers, and the weak review process to name a couple that I'd agree with. We should collect all observations from different types of add-on developer to have any hope of coming up with a resolution plan.

2. None of this is meant as direct criticism against NVAccess. We're all aware of the context surrounding NVDA as a project, and in many cases it would be unrealistic to expect some of the same polish around the area of development that a commercial vendor is seen to attain. Particularly when scripting or extending the screen reader is already quite a niche topic within a niche market. But nevertheless, there are opportunities to highlight the unique position in which NVDA falls, offering users a fully-featured, popular programming language with which to enrich its functionality. Clearly, it's not hitting the mark for many right now.

Regards,

James Scholes

On 22/12/2020 at 11: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?


Jamal