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


 

Well seems like you jamal and others know what to do.

I don't.


I do think though this has gone on for long enough, if you guys or anyone else who is in the know can fix whats broken, then go fix it please.

I am just a normal dumb user that can't program much more than a simple batch file certainly not like this.

There are a lot of upgrades going on, but may I remind all of the list in general that this is open source.

We don't have to complain all day about the crappy nature of the crap which is the current nvda systems, if you know how, go fix.

I don't have the slightest idea how to go about it nore can I be bothered because most of this does not effect my day to day thing but if you guys want to contribute instead of complaining about it, go and try and see what can be done.

I don't develop with anything.

I use github desktop to get all I need, I have choco which as most of what is needed including visual studeo tools and python auto installed, I have npm and node and install what I am supposed to.

Most stuff is packaged and just does.

From my little work with node though, github desktop, maybe git and the choco packages need to be installed, latest python for choco but you could load others.

Then I handle everything with npm though yarn is also another popular manager.

I know enough to get the manager running but thats about it.



On 24/12/2020 1:07 am, Christo de Klerk wrote:
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







Join nvda-addons@nvda-addons.groups.io to automatically receive all group messages.