Topics

FW: [Nvda-devel] Refactoring NVDA: some comments from a member of the NVDA add-ons list regarding controller client and others

 

Hi,
Ethin may have seen this, but for those not on nvda-devel list, below could be considered a statement from NV Access. Thanks.

-----Original Message-----
From: Michael Curran <mick@...>
Sent: Thursday, December 6, 2018 4:08 PM
To: NVDA screen reader development <nvda-devel@...>
Subject: Re: [Nvda-devel] Refactoring NVDA: some comments from a member of the NVDA add-ons list regarding controller client and others

Hi all,


On behalf of NV Access, I would like to assure people that NVDA is not dying as far as I can see. I will admit that over the last year, development had slowed down somewhat as Jamie moved to Mozilla, leaving me to run the company, and both Reef and myself only managing about 3 days of development each a week. However, over the last few months we have been slowly putting in place plans that would remove the financial and administration work burden off me, freeing me up to work on development almost full-time. Similarly, I believe Reef is also in a position to increase his development time as well.

In short, I am happy to state that the NVDA project should see a healthy increase in development hours from NV Access going into 2019.


In regards to issues: it is true that we mark some issues as external,
as in some cases, it is simply impossible for us to fix or work around
something without the participation of another company. In many cases we
have good relationships with these companies, and do our utmost to
ensure that the right information gets to the right people. But also
please respect that in many cases these companies are what keeps NV
Access and the NVDA project alive financially, thus there are a lot of
careful conversations going on behind the scenes.


NVDA is a very large open source project now, and there are many open
issues, with more being opened each day. You can appreciate that it is
extremely hard for us to identify just what is the most important to
work on, juggling user impact with our other contractual obligations
(which again allow us to do NVDA at all).

We will certainly take the feedback from this thread seriously, and do
urge people to write to Quentin or myself with suggestions of the top
most issues that are stopping you as an NVDA user from being productive.


Regards

Mick




On 07/12/2018 09:37, Ethin Probst wrote:
It is. I know. The question is, if NVDA is truly dying, what will
replace it? For the sandboxing thing, there already is a way to
sandbox (or outright remove) built-ins from a Python session like so:
import builtins
# remove print
del builtins.print
This works in both python 2.x and 3.x. The reason I ask about
replacements for NvDA is that I doubt any of us who use NVDA will be
remotely happy, or willing, to purchase a commercial screen reader.
Either the screen reader is two pricey, the people who maintain it are
sketchy, the reputation of that screen reader or the company behind it
is questionable, and so on. And yes, I've done that a lot (I had to
paste a 110k string into SSH yesterday, definitely had to press
alt+tab to stop it from spitting out everything).

On 12/6/18, Tyler Spivey <tspivey@...> wrote:
On your refactoring points...
The fact of the matter is that NVDA is dying.
There's one dev, and a few contributors. It just can't keep up.
User experience isn't a priority, see, for example, #8987. The standard
response is to ignore issues which are external, and not even attempt to
work around them until it impacts a *lot* of people (see the UIA fiasco
which was there for years).
Things are deteriorating fast.
Office performance is absolutely abysmal, NV Access recommends
MathPlayer which will break accessibility on your system if uninstalled
(but only for NVDA, not JAWS, which keeps working), etc.
And no, the COM registration tool doesn't fix that one.
I'm sure some of us long-time NVDA users can come up with more.
Your console issue isn't because of the controller, it's because NVDA
can't keep up. Between the screen diffing and sending all the text to
the synth, which has to do regex processing to various degrees depending
on what you use for a synth/the size of your dictionary/etc, it can
freeze and be difficult to recover from.
I'm sure we've all at some point ran a command, then immediately slammed
windows+m or alt+tab hopefully before it started speaking. This is
nothing new.

On 12/6/2018 1:32 PM, @joslee wrote:
Hi all,

Someone posted the below comments on NVDA add-ons list, and since he is
not a member of this list, I thought I’d forward his message so we can
tell him what’s going on. Thanks.



-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<mailto:nvda-addons@nvda-addons.groups.io>

<nvda-addons@nvda-addons.groups.io
<mailto:nvda-addons@nvda-addons.groups.io>>

On Behalf Of Ethin Probst
Sent: Thursday, December 6, 2018 12:55 PM
To: nvda-addons@nvda-addons.groups.io
<mailto:nvda-addons@nvda-addons.groups.io>

Subject: Re: [nvda-addons] [nvda-translations] [nvda] FW: [Nvda-devel]
Add-on compatibility in NVDA 2019.1 and beyond.
I'd like to ask, what is "speech refactor"? You've mentioned that
several times in your messages, and I'm confused about it. Also, if
we're going to be refactoring things, we might as well refactor the
way
NVDAControllerClient32/NvDAControllerClient64 work. Right now, with
some guessing, I've determined that the client just sends all the data
to the speech synthesizer at once, rather than either doing it
asynchronously or buffering it. This leads to some rather interesting
problems, like:

* When typing curl --help on the command line, it takes roughly 4.3
seconds or so for NVDA to actually begin speaking, which makes me
wonder if its feeding the text all at once to the synthesizer (causing
synthesizer overload), and the synthesizer spends all that time
attempting to process all of that text.
* On MUDs or in applications where a large amount of text is regularly
sent to the terminal or screen reader via the controller client, NvDA
tends to fall behind and lag horribly (if not outright crash) because
it receives too much data at once, or the controller client floods the
synthesizer.

Furthermore, some other interesting problems I've noticed:
* Currently, NVDA embeds itself via a main thread (and does not use
multithreading anywhere). This causes some huge issues; for example,
if an application crashes, it usually takes NVDA with it, or if NVDA
suffers an issue, it takes the application with it too. This causes
huge problems with people and I've heard many people complain about
this problem.

All of these problems need to be fixed. They've gone unfixed, and
there are various ways to fix them:
* for the controller client, buffer the incoming text (i.e. in
1024-byte
chunks) and feed the synthesizer these 1024-byte chunks every few
hundred milliseconds to give it time to deal with the text its already
gotten.

Preferably, do this on another thread, or an asynchronous event loop.
* For the embedding problem, spin off another thread that runs a
background asynchronous event loop when NVDA starts to handle
accessibility events from IAccessible2. If that thread crashes, handle
the crash gracefully -- restart the thread and continue the event loop
from the beginning, discarding all data up to that point and
regathering information as though nothing had happened and NVDA had
started the loop for the first time that run.

I'm saying that this needs to be fixed now because no other screen
reader suffers any of these problems. And if we want NVDA to become
popular, or widely used, this is one of the huge problems that needs
to be fixed.

Also, one final problem, and the reason that NVDA isn't usually
allowed in the workplace: the add-on system and built-in Python
interpreter via the console and other means. Right now, the Python
interpreter that executes add-ons, the python console, and so on, is
not sandboxed. This is an incredibly huge security hole that needs to
be fixed ASAP. As it currently stands, I see two major possibilities
to fix this problem:

1. Remove the ability to run Python add-ons and embed a custom parser
scripting language that users can write NVDA add-ons in. This is most
likely undesirable, but the safest option, since the NVDA Core has the
ability to control exactly what add-ons can do and what they can't.
2. Rewrite the entire Python 2/3 standard library to moderate what
functions users may execute. I.e.: rewrite the built-in functions like
open so that a user may only open files within a particular directory.
Disallow the ability to open DLLs with the ctypes module, unless
explicitly authorized by the user running the application.



_______________________________________________
Nvda-devel mailing list
Nvda-devel@...
https://lists.sourceforge.net/lists/listinfo/nvda-devel

_______________________________________________
Nvda-devel mailing list
Nvda-devel@...
https://lists.sourceforge.net/lists/listinfo/nvda-devel

_______________________________________________
Nvda-devel mailing list
Nvda-devel@...
https://lists.sourceforge.net/lists/listinfo/nvda-devel

Luis Carlos Gonzáles Moráles
 

Still didn't get any news for 4 years or so, neaither the new spanish
voices are there?

Joseph Lee wrote:

Hi,
Ethin may have seen this, but for those not on nvda-devel list, below could be considered a statement from NV Access. Thanks.

-----Original Message-----
From: Michael Curran <mick@...>
Sent: Thursday, December 6, 2018 4:08 PM
To: NVDA screen reader development <nvda-devel@...>
Subject: Re: [Nvda-devel] Refactoring NVDA: some comments from a member of the NVDA add-ons list regarding controller client and others

Hi all,


On behalf of NV Access, I would like to assure people that NVDA is not dying as far as I can see. I will admit that over the last year, development had slowed down somewhat as Jamie moved to Mozilla, leaving me to run the company, and both Reef and myself only managing about 3 days of development each a week. However, over the last few months we have been slowly putting in place plans that would remove the financial and administration work burden off me, freeing me up to work on development almost full-time. Similarly, I believe Reef is also in a position to increase his development time as well.

In short, I am happy to state that the NVDA project should see a healthy increase in development hours from NV Access going into 2019.


In regards to issues: it is true that we mark some issues as external,
as in some cases, it is simply impossible for us to fix or work around
something without the participation of another company. In many cases we
have good relationships with these companies, and do our utmost to
ensure that the right information gets to the right people. But also
please respect that in many cases these companies are what keeps NV
Access and the NVDA project alive financially, thus there are a lot of
careful conversations going on behind the scenes.


NVDA is a very large open source project now, and there are many open
issues, with more being opened each day. You can appreciate that it is
extremely hard for us to identify just what is the most important to
work on, juggling user impact with our other contractual obligations
(which again allow us to do NVDA at all).

We will certainly take the feedback from this thread seriously, and do
urge people to write to Quentin or myself with suggestions of the top
most issues that are stopping you as an NVDA user from being productive.


Regards

Mick




On 07/12/2018 09:37, Ethin Probst wrote:
It is. I know. The question is, if NVDA is truly dying, what will
replace it? For the sandboxing thing, there already is a way to
sandbox (or outright remove) built-ins from a Python session like so:
import builtins
# remove print
del builtins.print
This works in both python 2.x and 3.x. The reason I ask about
replacements for NvDA is that I doubt any of us who use NVDA will be
remotely happy, or willing, to purchase a commercial screen reader.
Either the screen reader is two pricey, the people who maintain it are
sketchy, the reputation of that screen reader or the company behind it
is questionable, and so on. And yes, I've done that a lot (I had to
paste a 110k string into SSH yesterday, definitely had to press
alt+tab to stop it from spitting out everything).

On 12/6/18, Tyler Spivey <tspivey@...> wrote:
On your refactoring points...
The fact of the matter is that NVDA is dying.
There's one dev, and a few contributors. It just can't keep up.
User experience isn't a priority, see, for example, #8987. The standard
response is to ignore issues which are external, and not even attempt to
work around them until it impacts a *lot* of people (see the UIA fiasco
which was there for years).
Things are deteriorating fast.
Office performance is absolutely abysmal, NV Access recommends
MathPlayer which will break accessibility on your system if uninstalled
(but only for NVDA, not JAWS, which keeps working), etc.
And no, the COM registration tool doesn't fix that one.
I'm sure some of us long-time NVDA users can come up with more.
Your console issue isn't because of the controller, it's because NVDA
can't keep up. Between the screen diffing and sending all the text to
the synth, which has to do regex processing to various degrees depending
on what you use for a synth/the size of your dictionary/etc, it can
freeze and be difficult to recover from.
I'm sure we've all at some point ran a command, then immediately slammed
windows+m or alt+tab hopefully before it started speaking. This is
nothing new.

On 12/6/2018 1:32 PM, @joslee wrote:
Hi all,

Someone posted the below comments on NVDA add-ons list, and since he is
not a member of this list, I thought I’d forward his message so we can
tell him what’s going on. Thanks.



-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<mailto:nvda-addons@nvda-addons.groups.io>

<nvda-addons@nvda-addons.groups.io
<mailto:nvda-addons@nvda-addons.groups.io>>

On Behalf Of Ethin Probst
Sent: Thursday, December 6, 2018 12:55 PM
To: nvda-addons@nvda-addons.groups.io
<mailto:nvda-addons@nvda-addons.groups.io>

Subject: Re: [nvda-addons] [nvda-translations] [nvda] FW: [Nvda-devel]
Add-on compatibility in NVDA 2019.1 and beyond.
I'd like to ask, what is "speech refactor"? You've mentioned that
several times in your messages, and I'm confused about it. Also, if
we're going to be refactoring things, we might as well refactor the
way
NVDAControllerClient32/NvDAControllerClient64 work. Right now, with
some guessing, I've determined that the client just sends all the data
to the speech synthesizer at once, rather than either doing it
asynchronously or buffering it. This leads to some rather interesting
problems, like:

* When typing curl --help on the command line, it takes roughly 4.3
seconds or so for NVDA to actually begin speaking, which makes me
wonder if its feeding the text all at once to the synthesizer (causing
synthesizer overload), and the synthesizer spends all that time
attempting to process all of that text.
* On MUDs or in applications where a large amount of text is regularly
sent to the terminal or screen reader via the controller client, NvDA
tends to fall behind and lag horribly (if not outright crash) because
it receives too much data at once, or the controller client floods the
synthesizer.

Furthermore, some other interesting problems I've noticed:
* Currently, NVDA embeds itself via a main thread (and does not use
multithreading anywhere). This causes some huge issues; for example,
if an application crashes, it usually takes NVDA with it, or if NVDA
suffers an issue, it takes the application with it too. This causes
huge problems with people and I've heard many people complain about
this problem.

All of these problems need to be fixed. They've gone unfixed, and
there are various ways to fix them:
* for the controller client, buffer the incoming text (i.e. in
1024-byte
chunks) and feed the synthesizer these 1024-byte chunks every few
hundred milliseconds to give it time to deal with the text its already
gotten.

Preferably, do this on another thread, or an asynchronous event loop.
* For the embedding problem, spin off another thread that runs a
background asynchronous event loop when NVDA starts to handle
accessibility events from IAccessible2. If that thread crashes, handle
the crash gracefully -- restart the thread and continue the event loop
from the beginning, discarding all data up to that point and
regathering information as though nothing had happened and NVDA had
started the loop for the first time that run.

I'm saying that this needs to be fixed now because no other screen
reader suffers any of these problems. And if we want NVDA to become
popular, or widely used, this is one of the huge problems that needs
to be fixed.

Also, one final problem, and the reason that NVDA isn't usually
allowed in the workplace: the add-on system and built-in Python
interpreter via the console and other means. Right now, the Python
interpreter that executes add-ons, the python console, and so on, is
not sandboxed. This is an incredibly huge security hole that needs to
be fixed ASAP. As it currently stands, I see two major possibilities
to fix this problem:

1. Remove the ability to run Python add-ons and embed a custom parser
scripting language that users can write NVDA add-ons in. This is most
likely undesirable, but the safest option, since the NVDA Core has the
ability to control exactly what add-ons can do and what they can't.
2. Rewrite the entire Python 2/3 standard library to moderate what
functions users may execute. I.e.: rewrite the built-in functions like
open so that a user may only open files within a particular directory.
Disallow the ability to open DLLs with the ctypes module, unless
explicitly authorized by the user running the application.


_______________________________________________
Nvda-devel mailing list
Nvda-devel@...
https://lists.sourceforge.net/lists/listinfo/nvda-devel
_______________________________________________
Nvda-devel mailing list
Nvda-devel@...
https://lists.sourceforge.net/lists/listinfo/nvda-devel
_______________________________________________
Nvda-devel mailing list
Nvda-devel@...
https://lists.sourceforge.net/lists/listinfo/nvda-devel