toggle quoted messageShow quoted text
Well seems like you jamal and others know what to do.
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
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
I know enough to get the manager running but thats about it.
On 24/12/2020 1:07 am, Christo de Klerk
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
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
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
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
On 2020/12/23 07:40am, Jamal Mazrui
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
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
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
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?