Topics

[nvda-translations] [nvda] FW: [Nvda-devel] Add-on compatibility in NVDA 2019.1 and beyond.

 

Hi,

The compatibility flag warning is a necessary stepping stone for two things that’ll have massive impact in our community: Python 3 and speech refactor. My position is that giving folks this warning early should let authors think about what to do and act accordingly.

As for incorporating some add-on features into NVDA Core: some might work, others won’t. At the moment my highest priority (besides studying for fall term finals and keeping an eye on Windows 10 updates) is Add-on Updater and incorporating that into NVDA.

As for NV Access taking over unmaintained add-ons: this depends on add-ons and surrounding copyright issues for some popular ones. For Vocalizer and friends, NV Access must reach out to Nuance about licensing and work with Code Factory and others regarding license transfer and what not. Unfortunately, there are speech synthesizers that won’t make the cut to Python 3 unless changes are made from authors, and it isn’t easy to contact authors for some to begin with.

As for advertising minimum and last tested NVDA versions for add-ons: I’d leave it up to authors to do this (both from manifest and on readme). Rest assured that my add-ons will ship with compatibility flags for future NVDA releases (both minimum and last tested versions defined and mentioned in the manifest and readme); this is the real reason for releasing version 18.12 of several of my add-ons: to prepare for what happened yesterday where compatibility flags are required. I’ll write up a more detailed announcement about compatibility flags for my add-ons later today.

Cheers,

Joseph

 

From: nvda-translations@groups.io <nvda-translations@groups.io> On Behalf Of Adriani Botez
Sent: Thursday, December 6, 2018 11:46 AM
To: nvda@nvda.groups.io
Cc: nvda-addons@nvda-addons.groups.io; nvda-translations@groups.io
Subject: Re: [nvda-translations] [nvda] FW: [Nvda-devel] Add-on compatibility in NVDA 2019.1 and beyond.

 

Hey Joseph,

 

thanks for forwarding this. However, then we should start working to adjust the add-on webpage so that the date of last update for an add-on is shown. The users could then decide much better if they install that add-on or not. But in my view this warning is a bit exagerated because some add-ons which are really useful are not regularly maintained by their original developers (i.e. audio theme 3d or even remote add-on where we see big delays in updating it). If NV Access really want to discourage users to use add-ons which are not updated regularly, then I think we should think about integrating useful functions into NVDA’s core. I mean functions from add-ons which are not maintained reliably. Because an add-on which is not maintained regularly does not mean that the add-on is not used by many users. Vocalizer for example is also not maintained regularly but, at least in Germany, about 60% of users use that add-on also at work. They would never change to eSpeak.

 

That’s why I think a survey worldwide would give us an orientation of which add-ons are used most often and whe can see which are regularly maintained and which not. After assessing the survey data NV Access can decide to overtake the add-ons which are abandoned or not updated for a very long time and integrate similar functions in NVDA.

 

But in long term we have to find a sustainable solution. Some statistics on the add-ons webpage would make this much easier (i.e. number of downloads for an add-on, last update and so on).

 

 

Best

Adriani

 

 

 

 

Von: nvda@nvda.groups.io <nvda@nvda.groups.io> Im Auftrag von Joseph Lee
Gesendet: Donnerstag, 6. Dezember 2018 15:23
An: nvda@nvda.groups.io
Betreff: [nvda] FW: [Nvda-devel] Add-on compatibility in NVDA 2019.1 and beyond.

 

Hi NVDA community,

Please read the following announcement from Reef Turner, one of the lead developers of NVDA. Although his announcement won’t have any impact on many of you now, the change he has outlined will show up for NVDA 2019.1.

Cheers,

Joseph

 

From: Reef Turner <reef@...>
Sent: Thursday, December 6, 2018 3:31 AM
To: NVDA screen reader development <nvda-devel@...>
Subject: [Nvda-devel] Add-on compatibility in NVDA 2019.1 and beyond.

 

In order to address some looming issues that will affect the stability of add-ons in future releases (speech refactor, Python 3), a new add-on compatibility mechanism has been introduced. The short version is that add-ons will need to be updated more regularly. For a seamless user experience add-ons should be tested against each new NVDA release, excluding minor releases, and updated. The first Beta would be a good choice to confirm the add-on will work as expected with the release. Users will be strongly discouraged from installing, or leaving enabled, add-ons that have not followed this process.

 

For all the gritty details, see the pull request #8006

--

Regards,

Reef Turner

Ethin Probst
 

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.

On 12/6/18, Joseph Lee <@joslee> wrote:
Hi,

The compatibility flag warning is a necessary stepping stone for two things
that’ll have massive impact in our community: Python 3 and speech refactor.
My position is that giving folks this warning early should let authors think
about what to do and act accordingly.

As for incorporating some add-on features into NVDA Core: some might work,
others won’t. At the moment my highest priority (besides studying for fall
term finals and keeping an eye on Windows 10 updates) is Add-on Updater and
incorporating that into NVDA.

As for NV Access taking over unmaintained add-ons: this depends on add-ons
and surrounding copyright issues for some popular ones. For Vocalizer and
friends, NV Access must reach out to Nuance about licensing and work with
Code Factory and others regarding license transfer and what not.
Unfortunately, there are speech synthesizers that won’t make the cut to
Python 3 unless changes are made from authors, and it isn’t easy to contact
authors for some to begin with.

As for advertising minimum and last tested NVDA versions for add-ons: I’d
leave it up to authors to do this (both from manifest and on readme). Rest
assured that my add-ons will ship with compatibility flags for future NVDA
releases (both minimum and last tested versions defined and mentioned in the
manifest and readme); this is the real reason for releasing version 18.12 of
several of my add-ons: to prepare for what happened yesterday where
compatibility flags are required. I’ll write up a more detailed announcement
about compatibility flags for my add-ons later today.

Cheers,

Joseph



From: nvda-translations@groups.io <nvda-translations@groups.io> On Behalf Of
Adriani Botez
Sent: Thursday, December 6, 2018 11:46 AM
To: nvda@nvda.groups.io
Cc: nvda-addons@nvda-addons.groups.io; nvda-translations@groups.io
Subject: Re: [nvda-translations] [nvda] FW: [Nvda-devel] Add-on
compatibility in NVDA 2019.1 and beyond.



Hey Joseph,



thanks for forwarding this. However, then we should start working to adjust
the add-on webpage so that the date of last update for an add-on is shown.
The users could then decide much better if they install that add-on or not.
But in my view this warning is a bit exagerated because some add-ons which
are really useful are not regularly maintained by their original developers
(i.e. audio theme 3d or even remote add-on where we see big delays in
updating it). If NV Access really want to discourage users to use add-ons
which are not updated regularly, then I think we should think about
integrating useful functions into NVDA’s core. I mean functions from add-ons
which are not maintained reliably. Because an add-on which is not maintained
regularly does not mean that the add-on is not used by many users. Vocalizer
for example is also not maintained regularly but, at least in Germany, about
60% of users use that add-on also at work. They would never change to
eSpeak.



That’s why I think a survey worldwide would give us an orientation of which
add-ons are used most often and whe can see which are regularly maintained
and which not. After assessing the survey data NV Access can decide to
overtake the add-ons which are abandoned or not updated for a very long time
and integrate similar functions in NVDA.



But in long term we have to find a sustainable solution. Some statistics on
the add-ons webpage would make this much easier (i.e. number of downloads
for an add-on, last update and so on).





Best

Adriani









Von: nvda@nvda.groups.io <mailto:nvda@nvda.groups.io> <nvda@nvda.groups.io
<mailto:nvda@nvda.groups.io> > Im Auftrag von Joseph Lee
Gesendet: Donnerstag, 6. Dezember 2018 15:23
An: nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
Betreff: [nvda] FW: [Nvda-devel] Add-on compatibility in NVDA 2019.1 and
beyond.



Hi NVDA community,

Please read the following announcement from Reef Turner, one of the lead
developers of NVDA. Although his announcement won’t have any impact on many
of you now, the change he has outlined will show up for NVDA 2019.1.

Cheers,

Joseph



From: Reef Turner <reef@... <mailto:reef@...> >
Sent: Thursday, December 6, 2018 3:31 AM
To: NVDA screen reader development <nvda-devel@...
<mailto:nvda-devel@...> >
Subject: [Nvda-devel] Add-on compatibility in NVDA 2019.1 and beyond.



In order to address some looming issues that will affect the stability of
add-ons in future releases (speech refactor, Python 3), a new add-on
compatibility mechanism has been introduced. The short version is that
add-ons will need to be updated more regularly. For a seamless user
experience add-ons should be tested against each new NVDA release, excluding
minor releases, and updated. The first Beta would be a good choice to
confirm the add-on will work as expected with the release. Users will be
strongly discouraged from installing, or leaving enabled, add-ons that have
not followed this process.



For all the gritty details, see the pull request #8006
<https://github.com/nvaccess/nvda/pull/8006>

--

Regards,

Reef Turner







--
Signed,
Ethin D. Probst

 

Hi,
Speech refactor is a collection of changes that attempts to provide additional capabilities for audio/speech output, including inserting emphasis, sounds to indicate actions/roles/states and what not.
As for multithreading problem, this was discussed at length before (need to dig into archives to find out which GitHub issue it was).
As for other development questions, this is best suited for nvda-devel list, not really on an add-ons list, as not all NVDA contributors are members of this list.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <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
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.

On 12/6/18, Joseph Lee <@joslee> wrote:
Hi,

The compatibility flag warning is a necessary stepping stone for two
things that’ll have massive impact in our community: Python 3 and speech refactor.
My position is that giving folks this warning early should let authors
think about what to do and act accordingly.

As for incorporating some add-on features into NVDA Core: some might
work, others won’t. At the moment my highest priority (besides
studying for fall term finals and keeping an eye on Windows 10
updates) is Add-on Updater and incorporating that into NVDA.

As for NV Access taking over unmaintained add-ons: this depends on
add-ons and surrounding copyright issues for some popular ones. For
Vocalizer and friends, NV Access must reach out to Nuance about
licensing and work with Code Factory and others regarding license transfer and what not.
Unfortunately, there are speech synthesizers that won’t make the cut
to Python 3 unless changes are made from authors, and it isn’t easy to
contact authors for some to begin with.

As for advertising minimum and last tested NVDA versions for add-ons:
I’d leave it up to authors to do this (both from manifest and on
readme). Rest assured that my add-ons will ship with compatibility
flags for future NVDA releases (both minimum and last tested versions
defined and mentioned in the manifest and readme); this is the real
reason for releasing version 18.12 of several of my add-ons: to
prepare for what happened yesterday where compatibility flags are
required. I’ll write up a more detailed announcement about compatibility flags for my add-ons later today.

Cheers,

Joseph



From: nvda-translations@groups.io <nvda-translations@groups.io> On
Behalf Of Adriani Botez
Sent: Thursday, December 6, 2018 11:46 AM
To: nvda@nvda.groups.io
Cc: nvda-addons@nvda-addons.groups.io; nvda-translations@groups.io
Subject: Re: [nvda-translations] [nvda] FW: [Nvda-devel] Add-on
compatibility in NVDA 2019.1 and beyond.



Hey Joseph,



thanks for forwarding this. However, then we should start working to
adjust the add-on webpage so that the date of last update for an add-on is shown.
The users could then decide much better if they install that add-on or not.
But in my view this warning is a bit exagerated because some add-ons
which are really useful are not regularly maintained by their original
developers (i.e. audio theme 3d or even remote add-on where we see big
delays in updating it). If NV Access really want to discourage users
to use add-ons which are not updated regularly, then I think we should
think about integrating useful functions into NVDA’s core. I mean
functions from add-ons which are not maintained reliably. Because an
add-on which is not maintained regularly does not mean that the add-on
is not used by many users. Vocalizer for example is also not
maintained regularly but, at least in Germany, about 60% of users use
that add-on also at work. They would never change to eSpeak.



That’s why I think a survey worldwide would give us an orientation of
which add-ons are used most often and whe can see which are regularly
maintained and which not. After assessing the survey data NV Access
can decide to overtake the add-ons which are abandoned or not updated
for a very long time and integrate similar functions in NVDA.



But in long term we have to find a sustainable solution. Some
statistics on the add-ons webpage would make this much easier (i.e.
number of downloads for an add-on, last update and so on).





Best

Adriani









Von: nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
<nvda@nvda.groups.io <mailto:nvda@nvda.groups.io> > Im Auftrag von
Joseph Lee
Gesendet: Donnerstag, 6. Dezember 2018 15:23
An: nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
Betreff: [nvda] FW: [Nvda-devel] Add-on compatibility in NVDA 2019.1
and beyond.



Hi NVDA community,

Please read the following announcement from Reef Turner, one of the
lead developers of NVDA. Although his announcement won’t have any
impact on many of you now, the change he has outlined will show up for NVDA 2019.1.

Cheers,

Joseph



From: Reef Turner <reef@... <mailto:reef@...> >
Sent: Thursday, December 6, 2018 3:31 AM
To: NVDA screen reader development <nvda-devel@...
<mailto:nvda-devel@...> >
Subject: [Nvda-devel] Add-on compatibility in NVDA 2019.1 and beyond.



In order to address some looming issues that will affect the stability
of add-ons in future releases (speech refactor, Python 3), a new
add-on compatibility mechanism has been introduced. The short version
is that add-ons will need to be updated more regularly. For a seamless
user experience add-ons should be tested against each new NVDA
release, excluding minor releases, and updated. The first Beta would
be a good choice to confirm the add-on will work as expected with the
release. Users will be strongly discouraged from installing, or
leaving enabled, add-ons that have not followed this process.



For all the gritty details, see the pull request #8006
<https://github.com/nvaccess/nvda/pull/8006>

--

Regards,

Reef Turner







--
Signed,
Ethin D. Probst

Ethin Probst
 

I'm not subscribed to the NVDA developer mailing list. I'm also not
sure how to subscribe to it. :D

On 12/6/18, Joseph Lee <@joslee> wrote:
Hi,
Speech refactor is a collection of changes that attempts to provide
additional capabilities for audio/speech output, including inserting
emphasis, sounds to indicate actions/roles/states and what not.
As for multithreading problem, this was discussed at length before (need to
dig into archives to find out which GitHub issue it was).
As for other development questions, this is best suited for nvda-devel list,
not really on an add-ons list, as not all NVDA contributors are members of
this list.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <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
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.

On 12/6/18, Joseph Lee <@joslee> wrote:
Hi,

The compatibility flag warning is a necessary stepping stone for two
things that’ll have massive impact in our community: Python 3 and speech
refactor.
My position is that giving folks this warning early should let authors
think about what to do and act accordingly.

As for incorporating some add-on features into NVDA Core: some might
work, others won’t. At the moment my highest priority (besides
studying for fall term finals and keeping an eye on Windows 10
updates) is Add-on Updater and incorporating that into NVDA.

As for NV Access taking over unmaintained add-ons: this depends on
add-ons and surrounding copyright issues for some popular ones. For
Vocalizer and friends, NV Access must reach out to Nuance about
licensing and work with Code Factory and others regarding license transfer
and what not.
Unfortunately, there are speech synthesizers that won’t make the cut
to Python 3 unless changes are made from authors, and it isn’t easy to
contact authors for some to begin with.

As for advertising minimum and last tested NVDA versions for add-ons:
I’d leave it up to authors to do this (both from manifest and on
readme). Rest assured that my add-ons will ship with compatibility
flags for future NVDA releases (both minimum and last tested versions
defined and mentioned in the manifest and readme); this is the real
reason for releasing version 18.12 of several of my add-ons: to
prepare for what happened yesterday where compatibility flags are
required. I’ll write up a more detailed announcement about compatibility
flags for my add-ons later today.

Cheers,

Joseph



From: nvda-translations@groups.io <nvda-translations@groups.io> On
Behalf Of Adriani Botez
Sent: Thursday, December 6, 2018 11:46 AM
To: nvda@nvda.groups.io
Cc: nvda-addons@nvda-addons.groups.io; nvda-translations@groups.io
Subject: Re: [nvda-translations] [nvda] FW: [Nvda-devel] Add-on
compatibility in NVDA 2019.1 and beyond.



Hey Joseph,



thanks for forwarding this. However, then we should start working to
adjust the add-on webpage so that the date of last update for an add-on is
shown.
The users could then decide much better if they install that add-on or
not.
But in my view this warning is a bit exagerated because some add-ons
which are really useful are not regularly maintained by their original
developers (i.e. audio theme 3d or even remote add-on where we see big
delays in updating it). If NV Access really want to discourage users
to use add-ons which are not updated regularly, then I think we should
think about integrating useful functions into NVDA’s core. I mean
functions from add-ons which are not maintained reliably. Because an
add-on which is not maintained regularly does not mean that the add-on
is not used by many users. Vocalizer for example is also not
maintained regularly but, at least in Germany, about 60% of users use
that add-on also at work. They would never change to eSpeak.



That’s why I think a survey worldwide would give us an orientation of
which add-ons are used most often and whe can see which are regularly
maintained and which not. After assessing the survey data NV Access
can decide to overtake the add-ons which are abandoned or not updated
for a very long time and integrate similar functions in NVDA.



But in long term we have to find a sustainable solution. Some
statistics on the add-ons webpage would make this much easier (i.e.
number of downloads for an add-on, last update and so on).





Best

Adriani









Von: nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
<nvda@nvda.groups.io <mailto:nvda@nvda.groups.io> > Im Auftrag von
Joseph Lee
Gesendet: Donnerstag, 6. Dezember 2018 15:23
An: nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
Betreff: [nvda] FW: [Nvda-devel] Add-on compatibility in NVDA 2019.1
and beyond.



Hi NVDA community,

Please read the following announcement from Reef Turner, one of the
lead developers of NVDA. Although his announcement won’t have any
impact on many of you now, the change he has outlined will show up for
NVDA 2019.1.

Cheers,

Joseph



From: Reef Turner <reef@... <mailto:reef@...> >
Sent: Thursday, December 6, 2018 3:31 AM
To: NVDA screen reader development <nvda-devel@...
<mailto:nvda-devel@...> >
Subject: [Nvda-devel] Add-on compatibility in NVDA 2019.1 and beyond.



In order to address some looming issues that will affect the stability
of add-ons in future releases (speech refactor, Python 3), a new
add-on compatibility mechanism has been introduced. The short version
is that add-ons will need to be updated more regularly. For a seamless
user experience add-ons should be tested against each new NVDA
release, excluding minor releases, and updated. The first Beta would
be a good choice to confirm the add-on will work as expected with the
release. Users will be strongly discouraged from installing, or
leaving enabled, add-ons that have not followed this process.



For all the gritty details, see the pull request #8006
<https://github.com/nvaccess/nvda/pull/8006>

--

Regards,

Reef Turner







--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst

 

Hi,
In this case, I'll forward your comments to nvad-devel list and report back as to what folks over there say.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Ethin Probst
Sent: Thursday, December 6, 2018 1:24 PM
To: 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'm not subscribed to the NVDA developer mailing list. I'm also not sure how to subscribe to it. :D

On 12/6/18, Joseph Lee <@joslee> wrote:
Hi,
Speech refactor is a collection of changes that attempts to provide
additional capabilities for audio/speech output, including inserting
emphasis, sounds to indicate actions/roles/states and what not.
As for multithreading problem, this was discussed at length before
(need to dig into archives to find out which GitHub issue it was).
As for other development questions, this is best suited for nvda-devel
list, not really on an add-ons list, as not all NVDA contributors are
members of this list.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<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
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.

On 12/6/18, Joseph Lee <@joslee> wrote:
Hi,

The compatibility flag warning is a necessary stepping stone for two
things that’ll have massive impact in our community: Python 3 and
speech refactor.
My position is that giving folks this warning early should let
authors think about what to do and act accordingly.

As for incorporating some add-on features into NVDA Core: some might
work, others won’t. At the moment my highest priority (besides
studying for fall term finals and keeping an eye on Windows 10
updates) is Add-on Updater and incorporating that into NVDA.

As for NV Access taking over unmaintained add-ons: this depends on
add-ons and surrounding copyright issues for some popular ones. For
Vocalizer and friends, NV Access must reach out to Nuance about
licensing and work with Code Factory and others regarding license
transfer and what not.
Unfortunately, there are speech synthesizers that won’t make the cut
to Python 3 unless changes are made from authors, and it isn’t easy
to contact authors for some to begin with.

As for advertising minimum and last tested NVDA versions for add-ons:
I’d leave it up to authors to do this (both from manifest and on
readme). Rest assured that my add-ons will ship with compatibility
flags for future NVDA releases (both minimum and last tested versions
defined and mentioned in the manifest and readme); this is the real
reason for releasing version 18.12 of several of my add-ons: to
prepare for what happened yesterday where compatibility flags are
required. I’ll write up a more detailed announcement about
compatibility flags for my add-ons later today.

Cheers,

Joseph



From: nvda-translations@groups.io <nvda-translations@groups.io> On
Behalf Of Adriani Botez
Sent: Thursday, December 6, 2018 11:46 AM
To: nvda@nvda.groups.io
Cc: nvda-addons@nvda-addons.groups.io; nvda-translations@groups.io
Subject: Re: [nvda-translations] [nvda] FW: [Nvda-devel] Add-on
compatibility in NVDA 2019.1 and beyond.



Hey Joseph,



thanks for forwarding this. However, then we should start working to
adjust the add-on webpage so that the date of last update for an
add-on is shown.
The users could then decide much better if they install that add-on
or not.
But in my view this warning is a bit exagerated because some add-ons
which are really useful are not regularly maintained by their
original developers (i.e. audio theme 3d or even remote add-on where
we see big delays in updating it). If NV Access really want to
discourage users to use add-ons which are not updated regularly, then
I think we should think about integrating useful functions into
NVDA’s core. I mean functions from add-ons which are not maintained
reliably. Because an add-on which is not maintained regularly does
not mean that the add-on is not used by many users. Vocalizer for
example is also not maintained regularly but, at least in Germany,
about 60% of users use that add-on also at work. They would never change to eSpeak.



That’s why I think a survey worldwide would give us an orientation of
which add-ons are used most often and whe can see which are regularly
maintained and which not. After assessing the survey data NV Access
can decide to overtake the add-ons which are abandoned or not updated
for a very long time and integrate similar functions in NVDA.



But in long term we have to find a sustainable solution. Some
statistics on the add-ons webpage would make this much easier (i.e.
number of downloads for an add-on, last update and so on).





Best

Adriani









Von: nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
<nvda@nvda.groups.io <mailto:nvda@nvda.groups.io> > Im Auftrag von
Joseph Lee
Gesendet: Donnerstag, 6. Dezember 2018 15:23
An: nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
Betreff: [nvda] FW: [Nvda-devel] Add-on compatibility in NVDA 2019.1
and beyond.



Hi NVDA community,

Please read the following announcement from Reef Turner, one of the
lead developers of NVDA. Although his announcement won’t have any
impact on many of you now, the change he has outlined will show up
for NVDA 2019.1.

Cheers,

Joseph



From: Reef Turner <reef@... <mailto:reef@...> >
Sent: Thursday, December 6, 2018 3:31 AM
To: NVDA screen reader development <nvda-devel@...
<mailto:nvda-devel@...> >
Subject: [Nvda-devel] Add-on compatibility in NVDA 2019.1 and beyond.



In order to address some looming issues that will affect the
stability of add-ons in future releases (speech refactor, Python 3),
a new add-on compatibility mechanism has been introduced. The short
version is that add-ons will need to be updated more regularly. For a
seamless user experience add-ons should be tested against each new
NVDA release, excluding minor releases, and updated. The first Beta
would be a good choice to confirm the add-on will work as expected
with the release. Users will be strongly discouraged from installing,
or leaving enabled, add-ons that have not followed this process.



For all the gritty details, see the pull request #8006
<https://github.com/nvaccess/nvda/pull/8006>

--

Regards,

Reef Turner







--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst

Tyler Spivey
 

You could, you know, actually tell him how to subscribe.

You can subscribe here:
https://lists.sourceforge.net/lists/listinfo/nvda-devel

On 12/6/2018 1:29 PM, Joseph Lee wrote:
Hi,
In this case, I'll forward your comments to nvad-devel list and report back as to what folks over there say.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Ethin Probst
Sent: Thursday, December 6, 2018 1:24 PM
To: 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'm not subscribed to the NVDA developer mailing list. I'm also not sure how to subscribe to it. :D

On 12/6/18, Joseph Lee <@joslee> wrote:
Hi,
Speech refactor is a collection of changes that attempts to provide
additional capabilities for audio/speech output, including inserting
emphasis, sounds to indicate actions/roles/states and what not.
As for multithreading problem, this was discussed at length before
(need to dig into archives to find out which GitHub issue it was).
As for other development questions, this is best suited for nvda-devel
list, not really on an add-ons list, as not all NVDA contributors are
members of this list.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<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
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.

On 12/6/18, Joseph Lee <@joslee> wrote:
Hi,

The compatibility flag warning is a necessary stepping stone for two
things that’ll have massive impact in our community: Python 3 and
speech refactor.
My position is that giving folks this warning early should let
authors think about what to do and act accordingly.

As for incorporating some add-on features into NVDA Core: some might
work, others won’t. At the moment my highest priority (besides
studying for fall term finals and keeping an eye on Windows 10
updates) is Add-on Updater and incorporating that into NVDA.

As for NV Access taking over unmaintained add-ons: this depends on
add-ons and surrounding copyright issues for some popular ones. For
Vocalizer and friends, NV Access must reach out to Nuance about
licensing and work with Code Factory and others regarding license
transfer and what not.
Unfortunately, there are speech synthesizers that won’t make the cut
to Python 3 unless changes are made from authors, and it isn’t easy
to contact authors for some to begin with.

As for advertising minimum and last tested NVDA versions for add-ons:
I’d leave it up to authors to do this (both from manifest and on
readme). Rest assured that my add-ons will ship with compatibility
flags for future NVDA releases (both minimum and last tested versions
defined and mentioned in the manifest and readme); this is the real
reason for releasing version 18.12 of several of my add-ons: to
prepare for what happened yesterday where compatibility flags are
required. I’ll write up a more detailed announcement about
compatibility flags for my add-ons later today.

Cheers,

Joseph



From: nvda-translations@groups.io <nvda-translations@groups.io> On
Behalf Of Adriani Botez
Sent: Thursday, December 6, 2018 11:46 AM
To: nvda@nvda.groups.io
Cc: nvda-addons@nvda-addons.groups.io; nvda-translations@groups.io
Subject: Re: [nvda-translations] [nvda] FW: [Nvda-devel] Add-on
compatibility in NVDA 2019.1 and beyond.



Hey Joseph,



thanks for forwarding this. However, then we should start working to
adjust the add-on webpage so that the date of last update for an
add-on is shown.
The users could then decide much better if they install that add-on
or not.
But in my view this warning is a bit exagerated because some add-ons
which are really useful are not regularly maintained by their
original developers (i.e. audio theme 3d or even remote add-on where
we see big delays in updating it). If NV Access really want to
discourage users to use add-ons which are not updated regularly, then
I think we should think about integrating useful functions into
NVDA’s core. I mean functions from add-ons which are not maintained
reliably. Because an add-on which is not maintained regularly does
not mean that the add-on is not used by many users. Vocalizer for
example is also not maintained regularly but, at least in Germany,
about 60% of users use that add-on also at work. They would never change to eSpeak.



That’s why I think a survey worldwide would give us an orientation of
which add-ons are used most often and whe can see which are regularly
maintained and which not. After assessing the survey data NV Access
can decide to overtake the add-ons which are abandoned or not updated
for a very long time and integrate similar functions in NVDA.



But in long term we have to find a sustainable solution. Some
statistics on the add-ons webpage would make this much easier (i.e.
number of downloads for an add-on, last update and so on).





Best

Adriani









Von: nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
<nvda@nvda.groups.io <mailto:nvda@nvda.groups.io> > Im Auftrag von
Joseph Lee
Gesendet: Donnerstag, 6. Dezember 2018 15:23
An: nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
Betreff: [nvda] FW: [Nvda-devel] Add-on compatibility in NVDA 2019.1
and beyond.



Hi NVDA community,

Please read the following announcement from Reef Turner, one of the
lead developers of NVDA. Although his announcement won’t have any
impact on many of you now, the change he has outlined will show up
for NVDA 2019.1.

Cheers,

Joseph



From: Reef Turner <reef@... <mailto:reef@...> >
Sent: Thursday, December 6, 2018 3:31 AM
To: NVDA screen reader development <nvda-devel@...
<mailto:nvda-devel@...> >
Subject: [Nvda-devel] Add-on compatibility in NVDA 2019.1 and beyond.



In order to address some looming issues that will affect the
stability of add-ons in future releases (speech refactor, Python 3),
a new add-on compatibility mechanism has been introduced. The short
version is that add-ons will need to be updated more regularly. For a
seamless user experience add-ons should be tested against each new
NVDA release, excluding minor releases, and updated. The first Beta
would be a good choice to confirm the add-on will work as expected
with the release. Users will be strongly discouraged from installing,
or leaving enabled, add-ons that have not followed this process.



For all the gritty details, see the pull request #8006
<https://github.com/nvaccess/nvda/pull/8006>

--

Regards,

Reef Turner







--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst





Ethin Probst
 

Thanks, Tyler. I'll probably wait for Joseph to forward, then include
the functions I think should be sandboxed (the built-ins, I mean).
Sandboxing the modules themselves (os, time, ...) will require import
hooks, since we don't want to break the import system.

On 12/6/18, Tyler Spivey <tspivey@...> wrote:
You could, you know, actually tell him how to subscribe.

You can subscribe here:
https://lists.sourceforge.net/lists/listinfo/nvda-devel

On 12/6/2018 1:29 PM, Joseph Lee wrote:
Hi,
In this case, I'll forward your comments to nvad-devel list and report
back as to what folks over there say.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> On Behalf Of Ethin Probst
Sent: Thursday, December 6, 2018 1:24 PM
To: 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'm not subscribed to the NVDA developer mailing list. I'm also not sure
how to subscribe to it. :D

On 12/6/18, Joseph Lee <@joslee> wrote:
Hi,
Speech refactor is a collection of changes that attempts to provide
additional capabilities for audio/speech output, including inserting
emphasis, sounds to indicate actions/roles/states and what not.
As for multithreading problem, this was discussed at length before
(need to dig into archives to find out which GitHub issue it was).
As for other development questions, this is best suited for nvda-devel
list, not really on an add-ons list, as not all NVDA contributors are
members of this list.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<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
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.

On 12/6/18, Joseph Lee <@joslee> wrote:
Hi,

The compatibility flag warning is a necessary stepping stone for two
things that’ll have massive impact in our community: Python 3 and
speech refactor.
My position is that giving folks this warning early should let
authors think about what to do and act accordingly.

As for incorporating some add-on features into NVDA Core: some might
work, others won’t. At the moment my highest priority (besides
studying for fall term finals and keeping an eye on Windows 10
updates) is Add-on Updater and incorporating that into NVDA.

As for NV Access taking over unmaintained add-ons: this depends on
add-ons and surrounding copyright issues for some popular ones. For
Vocalizer and friends, NV Access must reach out to Nuance about
licensing and work with Code Factory and others regarding license
transfer and what not.
Unfortunately, there are speech synthesizers that won’t make the cut
to Python 3 unless changes are made from authors, and it isn’t easy
to contact authors for some to begin with.

As for advertising minimum and last tested NVDA versions for add-ons:
I’d leave it up to authors to do this (both from manifest and on
readme). Rest assured that my add-ons will ship with compatibility
flags for future NVDA releases (both minimum and last tested versions
defined and mentioned in the manifest and readme); this is the real
reason for releasing version 18.12 of several of my add-ons: to
prepare for what happened yesterday where compatibility flags are
required. I’ll write up a more detailed announcement about
compatibility flags for my add-ons later today.

Cheers,

Joseph



From: nvda-translations@groups.io <nvda-translations@groups.io> On
Behalf Of Adriani Botez
Sent: Thursday, December 6, 2018 11:46 AM
To: nvda@nvda.groups.io
Cc: nvda-addons@nvda-addons.groups.io; nvda-translations@groups.io
Subject: Re: [nvda-translations] [nvda] FW: [Nvda-devel] Add-on
compatibility in NVDA 2019.1 and beyond.



Hey Joseph,



thanks for forwarding this. However, then we should start working to
adjust the add-on webpage so that the date of last update for an
add-on is shown.
The users could then decide much better if they install that add-on
or not.
But in my view this warning is a bit exagerated because some add-ons
which are really useful are not regularly maintained by their
original developers (i.e. audio theme 3d or even remote add-on where
we see big delays in updating it). If NV Access really want to
discourage users to use add-ons which are not updated regularly, then
I think we should think about integrating useful functions into
NVDA’s core. I mean functions from add-ons which are not maintained
reliably. Because an add-on which is not maintained regularly does
not mean that the add-on is not used by many users. Vocalizer for
example is also not maintained regularly but, at least in Germany,
about 60% of users use that add-on also at work. They would never change
to eSpeak.



That’s why I think a survey worldwide would give us an orientation of
which add-ons are used most often and whe can see which are regularly
maintained and which not. After assessing the survey data NV Access
can decide to overtake the add-ons which are abandoned or not updated
for a very long time and integrate similar functions in NVDA.



But in long term we have to find a sustainable solution. Some
statistics on the add-ons webpage would make this much easier (i.e.
number of downloads for an add-on, last update and so on).





Best

Adriani









Von: nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
<nvda@nvda.groups.io <mailto:nvda@nvda.groups.io> > Im Auftrag von
Joseph Lee
Gesendet: Donnerstag, 6. Dezember 2018 15:23
An: nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
Betreff: [nvda] FW: [Nvda-devel] Add-on compatibility in NVDA 2019.1
and beyond.



Hi NVDA community,

Please read the following announcement from Reef Turner, one of the
lead developers of NVDA. Although his announcement won’t have any
impact on many of you now, the change he has outlined will show up
for NVDA 2019.1.

Cheers,

Joseph



From: Reef Turner <reef@... <mailto:reef@...> >
Sent: Thursday, December 6, 2018 3:31 AM
To: NVDA screen reader development <nvda-devel@...
<mailto:nvda-devel@...> >
Subject: [Nvda-devel] Add-on compatibility in NVDA 2019.1 and beyond.



In order to address some looming issues that will affect the
stability of add-ons in future releases (speech refactor, Python 3),
a new add-on compatibility mechanism has been introduced. The short
version is that add-ons will need to be updated more regularly. For a
seamless user experience add-ons should be tested against each new
NVDA release, excluding minor releases, and updated. The first Beta
would be a good choice to confirm the add-on will work as expected
with the release. Users will be strongly discouraged from installing,
or leaving enabled, add-ons that have not followed this process.



For all the gritty details, see the pull request #8006
<https://github.com/nvaccess/nvda/pull/8006>

--

Regards,

Reef Turner







--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst









--
Signed,
Ethin D. Probst

 

Hi,
I have already forwarded the email to developers. I advise sending a message to that list, telling folks who you are and proceed by sending your email you sent here. That way I can verify that it was you who sent the message I forwarded and you can get answers directly from members of the development list.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Ethin Probst
Sent: Thursday, December 6, 2018 2:03 PM
To: 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.

Thanks, Tyler. I'll probably wait for Joseph to forward, then include the functions I think should be sandboxed (the built-ins, I mean).
Sandboxing the modules themselves (os, time, ...) will require import hooks, since we don't want to break the import system.

On 12/6/18, Tyler Spivey <tspivey@...> wrote:
You could, you know, actually tell him how to subscribe.

You can subscribe here:
https://lists.sourceforge.net/lists/listinfo/nvda-devel

On 12/6/2018 1:29 PM, Joseph Lee wrote:
Hi,
In this case, I'll forward your comments to nvad-devel list and
report back as to what folks over there say.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> On Behalf Of Ethin Probst
Sent: Thursday, December 6, 2018 1:24 PM
To: 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'm not subscribed to the NVDA developer mailing list. I'm also not
sure how to subscribe to it. :D

On 12/6/18, Joseph Lee <@joslee> wrote:
Hi,
Speech refactor is a collection of changes that attempts to provide
additional capabilities for audio/speech output, including inserting
emphasis, sounds to indicate actions/roles/states and what not.
As for multithreading problem, this was discussed at length before
(need to dig into archives to find out which GitHub issue it was).
As for other development questions, this is best suited for
nvda-devel list, not really on an add-ons list, as not all NVDA
contributors are members of this list.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<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
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.

On 12/6/18, Joseph Lee <@joslee> wrote:
Hi,

The compatibility flag warning is a necessary stepping stone for
two things that’ll have massive impact in our community: Python 3
and speech refactor.
My position is that giving folks this warning early should let
authors think about what to do and act accordingly.

As for incorporating some add-on features into NVDA Core: some
might work, others won’t. At the moment my highest priority
(besides studying for fall term finals and keeping an eye on
Windows 10
updates) is Add-on Updater and incorporating that into NVDA.

As for NV Access taking over unmaintained add-ons: this depends on
add-ons and surrounding copyright issues for some popular ones. For
Vocalizer and friends, NV Access must reach out to Nuance about
licensing and work with Code Factory and others regarding license
transfer and what not.
Unfortunately, there are speech synthesizers that won’t make the
cut to Python 3 unless changes are made from authors, and it isn’t
easy to contact authors for some to begin with.

As for advertising minimum and last tested NVDA versions for add-ons:
I’d leave it up to authors to do this (both from manifest and on
readme). Rest assured that my add-ons will ship with compatibility
flags for future NVDA releases (both minimum and last tested
versions defined and mentioned in the manifest and readme); this is
the real reason for releasing version 18.12 of several of my
add-ons: to prepare for what happened yesterday where compatibility
flags are required. I’ll write up a more detailed announcement
about compatibility flags for my add-ons later today.

Cheers,

Joseph



From: nvda-translations@groups.io <nvda-translations@groups.io> On
Behalf Of Adriani Botez
Sent: Thursday, December 6, 2018 11:46 AM
To: nvda@nvda.groups.io
Cc: nvda-addons@nvda-addons.groups.io; nvda-translations@groups.io
Subject: Re: [nvda-translations] [nvda] FW: [Nvda-devel] Add-on
compatibility in NVDA 2019.1 and beyond.



Hey Joseph,



thanks for forwarding this. However, then we should start working
to adjust the add-on webpage so that the date of last update for an
add-on is shown.
The users could then decide much better if they install that add-on
or not.
But in my view this warning is a bit exagerated because some
add-ons which are really useful are not regularly maintained by
their original developers (i.e. audio theme 3d or even remote
add-on where we see big delays in updating it). If NV Access really
want to discourage users to use add-ons which are not updated
regularly, then I think we should think about integrating useful
functions into NVDA’s core. I mean functions from add-ons which are
not maintained reliably. Because an add-on which is not maintained
regularly does not mean that the add-on is not used by many users.
Vocalizer for example is also not maintained regularly but, at
least in Germany, about 60% of users use that add-on also at work.
They would never change to eSpeak.



That’s why I think a survey worldwide would give us an orientation
of which add-ons are used most often and whe can see which are
regularly maintained and which not. After assessing the survey data
NV Access can decide to overtake the add-ons which are abandoned or
not updated for a very long time and integrate similar functions in NVDA.



But in long term we have to find a sustainable solution. Some
statistics on the add-ons webpage would make this much easier (i.e.
number of downloads for an add-on, last update and so on).





Best

Adriani









Von: nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
<nvda@nvda.groups.io <mailto:nvda@nvda.groups.io> > Im Auftrag von
Joseph Lee
Gesendet: Donnerstag, 6. Dezember 2018 15:23
An: nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
Betreff: [nvda] FW: [Nvda-devel] Add-on compatibility in NVDA
2019.1 and beyond.



Hi NVDA community,

Please read the following announcement from Reef Turner, one of the
lead developers of NVDA. Although his announcement won’t have any
impact on many of you now, the change he has outlined will show up
for NVDA 2019.1.

Cheers,

Joseph



From: Reef Turner <reef@... <mailto:reef@...> >
Sent: Thursday, December 6, 2018 3:31 AM
To: NVDA screen reader development
<nvda-devel@...
<mailto:nvda-devel@...> >
Subject: [Nvda-devel] Add-on compatibility in NVDA 2019.1 and beyond.



In order to address some looming issues that will affect the
stability of add-ons in future releases (speech refactor, Python
3), a new add-on compatibility mechanism has been introduced. The
short version is that add-ons will need to be updated more
regularly. For a seamless user experience add-ons should be tested
against each new NVDA release, excluding minor releases, and
updated. The first Beta would be a good choice to confirm the
add-on will work as expected with the release. Users will be
strongly discouraged from installing, or leaving enabled, add-ons that have not followed this process.



For all the gritty details, see the pull request #8006
<https://github.com/nvaccess/nvda/pull/8006>

--

Regards,

Reef Turner







--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst









--
Signed,
Ethin D. Probst

Brian's Mail list account
 

I think though that you risk leaving a lot of people behind on the last useable version of NVDa for popular add ons not incorporated. I know that the devs want to move to Python 3, but its not too late to rethink this.
It depends on whether nvda has a future or not in the current landscape. For those interested there is a discussion on g the dev list.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.

----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-translations@groups.io>; <nvda@nvda.groups.io>
Cc: <nvda-addons@nvda-addons.groups.io>
Sent: Thursday, December 06, 2018 8:00 PM
Subject: Re: [nvda-addons] [nvda-translations] [nvda] FW: [Nvda-devel] Add-on compatibility in NVDA 2019.1 and beyond.


Hi,

The compatibility flag warning is a necessary stepping stone for two things that’ll have massive impact in our community: Python 3 and speech refactor. My position is that giving folks this warning early should let authors think about what to do and act accordingly.

As for incorporating some add-on features into NVDA Core: some might work, others won’t. At the moment my highest priority (besides studying for fall term finals and keeping an eye on Windows 10 updates) is Add-on Updater and incorporating that into NVDA.

As for NV Access taking over unmaintained add-ons: this depends on add-ons and surrounding copyright issues for some popular ones. For Vocalizer and friends, NV Access must reach out to Nuance about licensing and work with Code Factory and others regarding license transfer and what not. Unfortunately, there are speech synthesizers that won’t make the cut to Python 3 unless changes are made from authors, and it isn’t easy to contact authors for some to begin with.

As for advertising minimum and last tested NVDA versions for add-ons: I’d leave it up to authors to do this (both from manifest and on readme). Rest assured that my add-ons will ship with compatibility flags for future NVDA releases (both minimum and last tested versions defined and mentioned in the manifest and readme); this is the real reason for releasing version 18.12 of several of my add-ons: to prepare for what happened yesterday where compatibility flags are required. I’ll write up a more detailed announcement about compatibility flags for my add-ons later today.

Cheers,

Joseph



From: nvda-translations@groups.io <nvda-translations@groups.io> On Behalf Of Adriani Botez
Sent: Thursday, December 6, 2018 11:46 AM
To: nvda@nvda.groups.io
Cc: nvda-addons@nvda-addons.groups.io; nvda-translations@groups.io
Subject: Re: [nvda-translations] [nvda] FW: [Nvda-devel] Add-on compatibility in NVDA 2019.1 and beyond.



Hey Joseph,



thanks for forwarding this. However, then we should start working to adjust the add-on webpage so that the date of last update for an add-on is shown. The users could then decide much better if they install that add-on or not. But in my view this warning is a bit exagerated because some add-ons which are really useful are not regularly maintained by their original developers (i.e. audio theme 3d or even remote add-on where we see big delays in updating it). If NV Access really want to discourage users to use add-ons which are not updated regularly, then I think we should think about integrating useful functions into NVDA’s core. I mean functions from add-ons which are not maintained reliably. Because an add-on which is not maintained regularly does not mean that the add-on is not used by many users. Vocalizer for example is also not maintained regularly but, at least in Germany, about 60% of users use that add-on also at work. They would never change to eSpeak.



That’s why I think a survey worldwide would give us an orientation of which add-ons are used most often and whe can see which are regularly maintained and which not. After assessing the survey data NV Access can decide to overtake the add-ons which are abandoned or not updated for a very long time and integrate similar functions in NVDA.



But in long term we have to find a sustainable solution. Some statistics on the add-ons webpage would make this much easier (i.e. number of downloads for an add-on, last update and so on).





Best

Adriani









Von: nvda@nvda.groups.io <mailto:nvda@nvda.groups.io> <nvda@nvda.groups.io <mailto:nvda@nvda.groups.io> > Im Auftrag von Joseph Lee
Gesendet: Donnerstag, 6. Dezember 2018 15:23
An: nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
Betreff: [nvda] FW: [Nvda-devel] Add-on compatibility in NVDA 2019.1 and beyond.



Hi NVDA community,

Please read the following announcement from Reef Turner, one of the lead developers of NVDA. Although his announcement won’t have any impact on many of you now, the change he has outlined will show up for NVDA 2019.1.

Cheers,

Joseph



From: Reef Turner <reef@... <mailto:reef@...> >
Sent: Thursday, December 6, 2018 3:31 AM
To: NVDA screen reader development <nvda-devel@... <mailto:nvda-devel@...> >
Subject: [Nvda-devel] Add-on compatibility in NVDA 2019.1 and beyond.



In order to address some looming issues that will affect the stability of add-ons in future releases (speech refactor, Python 3), a new add-on compatibility mechanism has been introduced. The short version is that add-ons will need to be updated more regularly. For a seamless user experience add-ons should be tested against each new NVDA release, excluding minor releases, and updated. The first Beta would be a good choice to confirm the add-on will work as expected with the release. Users will be strongly discouraged from installing, or leaving enabled, add-ons that have not followed this process.



For all the gritty details, see the pull request #8006 <https://github.com/nvaccess/nvda/pull/8006>

--

Regards,

Reef Turner