Important notice: a note or two about future compatibility of add-ons on community add-ons website and elsewhere


 

Dear NVDA community,

 

This is Joseph Lee, one of the code contributors to NVDA screen reader project and a reviewer of community add-ons. I would like to take this time to update you on what’s been happening in regards to future compatibility of add-ons hosted on various websites, as well as rationale for compatibility notices you’re seeing from recent NVDA development releases (chiefly on alpha channel).

 

As of December 6, 2018, NVDA 2019.1 alpha snapshots (build 16382 onwards) will prompt you to check compatibility of various add-ons when you’re installing snapshots. This is because NVDA will now check if any of your add-ons are compatible with it by looking at two new manifest keys. These add-on manifest keys will tell NVDA if a given add-on is compatible with latest NVDA release, as well as providing a minimum compatible NVDA version if specified. After installing that alpha build and beyond, if NVDA detects one or more add-ons are not compatible, it will present a dialog at start up asking you to check which add-ons you still wish to use despite them being flagged as incompatible. This will be noticeable if you are using a third-party speech synthesizer or braille display by default and somehow these are not loading. Also, when trying to install new add-ons, if NVDA sees the add-on is incompatible, it’ll prompt a warning about it.

 

Prior to this change, you can install add-ons on any NVDA release (including upcoming 2018.4), and it was up to add-ons to use features provided by a given NVDA release. This meant really old add-ons could be installed, and if not optimized for recent NVDA releases, the add-on would not work as intended, and in some cases, fail to run outright. Some add-ons do have specific NVDA version requirements, but not all add-ons take advantage of this recommendation.

 

There are several reasons for the change as described above:

 

  1. Python 3 transition: as some of you (I think, at this point, more people) may know, NV Access and several developers (including I) are researching possible roadblocks to Python 3 transition, and I’m maintaining an actual Python 3 version of NVDA for testing purposes. Given massive differences between Python 2 and 3, it was felt to place add-on compatibility checks in place so you won’t install add-ons written in Python 2 on a Python 3 version of NVDA. This is one of the reasons for adding minimum NVDA version checks for add-ons if appropriate. As of today (December 8, 2018), at least three add-ons are Python 3 ready (thus will require newer NVDA versions in the future), and I expect that number to grow significantly in the next few months; the three compatible add-ons are Resource Monitor, SystrayList, and Windows 10 App Essentials, with StationPlaylist Studio to be added to this list in January 2019.
  2. Various internal work planned for the future: these include projects such as speech refactor (changing internals behind NVDA’s speech functionality) and such that will cause some add-ons to fail to work as advertised.

 

The new compatibility flags are:

 

  • minimumNVDAVersion: specifies minimum version of NVDA the add-on is compatible with.
  • lastTestedNVDAVersion: latest compatible NVDA version for the add-on.

 

These manifest keys are optional for now; in 2019, they will become mandatory for ALL add-ons. I would go so far as say that they are MANDATORY from now on, especially if you need to test your add-ons in alpha snapshots and intend to produce a Python 3 version of your add-ons.

 

As of December 8, 2018, only several add-ons hosted on community add-ons website (addons.nvda-project.org) are truly future-proof (compatibility flags are present). The good news is that add-on authors do understand the impact this change will have on their add-ons and some have begun updating their add-ons to add compatibility flags; others plan to add changes once 2019.1 enters beta testing phase (based on past conversations), while the community lost contact with authors of some add-ons (some of which are popular) and their add-ons will be flagged as incompatible unless updates are released.

 

The following add-ons are NVDA 2019.1 compatible and thus won’t cause NVDA to flag them as incompatible:

 

  • Add-on Updater
  • Easy Table Navigator
  • Enhanced Touch Gestures
  • Focus Highlight
  • Golden Cursor
  • GoldWave
  • ObjPad
  • Object Location Tones
  • Resource Monitor
  • StationPlaylist Studio
  • SystrayList
  • Unicode Braille Input
  • Virtual Review
  • Windows 10 App Essentials
  • And possibly more.

 

For add-ons not listed:

 

  • For users: please contact authors of add-ons you’re using and ask for their thoughts and plans for add-on compatibility flags and other future work (see below for words about my add-ons).
  • For developers: please think about the impact of this change and update your add-ons. I don’t expect all add-ons to be made compatible by the time 2019.1 stable version (or release candidate) is released, but at least for popular ones, please have your add-ons made compatible by the time 2019.1 beta 1 shows up. Also, I advise setting last tested version to 2019.2 so you can have plenty of time modernizing add-ons.

 

Notes for users of my add-ons or add-ons that’ll be reviewed by me:

 

  • For users: I expect all my add-ons (at least ones currently under active support) to be made Python 3 ready no later than March 2019. As far as last tested version flag is concerned, I’ll try my best to target later NVDA releases (for example, if using an add-on in NVDA 2019.1, the compatibility flag will indicate support for at least NvDA 2019.3) so you won’t have to worry about compatibility flag problems for a long time; compatibility flags (at least last tested version flag) will be updated once or twice a year.
  • For add-ons to be reviewed: I will look for compatibility flags (as part of user experience portion of basic review) starting from February 2019; other add-on reviewers may or may not look for these flags.
  • For Add-on Updater users: I will start enforcing add-on compatibility flags from version 19.03; that is, Add-on Updater will refuse to install add-on updates if they do not specify at least last tested version flag to align with NVDA 2019.1 behavior.

 

Thank you.

Cheers,

Joseph


David Goldfield
 

Joseph,

Thank you for alerting us to this situation. I am somewhat concerned as I do use some third-party add-ons not hosted on the community add-ons page but which are well-known and legal. I'm wondering if the developers of these add-ons have been informed about this change? Specifically, I use the Code Factory Eloquence and Vocalizer add-on, Acapela voices, Dictation Bridge and NVDA Remote. I also hope that Clipspeak and Clip Contents Designer will be updated but I realize these are not your apps.

Thank you again.


David Goldfield, Assistive Technology Specialist WWW.David-Goldfield.Com

On 12/8/2018 12:30 AM, Joseph Lee wrote:

Dear NVDA community,

 

This is Joseph Lee, one of the code contributors to NVDA screen reader project and a reviewer of community add-ons. I would like to take this time to update you on what’s been happening in regards to future compatibility of add-ons hosted on various websites, as well as rationale for compatibility notices you’re seeing from recent NVDA development releases (chiefly on alpha channel).

 

As of December 6, 2018, NVDA 2019.1 alpha snapshots (build 16382 onwards) will prompt you to check compatibility of various add-ons when you’re installing snapshots. This is because NVDA will now check if any of your add-ons are compatible with it by looking at two new manifest keys. These add-on manifest keys will tell NVDA if a given add-on is compatible with latest NVDA release, as well as providing a minimum compatible NVDA version if specified. After installing that alpha build and beyond, if NVDA detects one or more add-ons are not compatible, it will present a dialog at start up asking you to check which add-ons you still wish to use despite them being flagged as incompatible. This will be noticeable if you are using a third-party speech synthesizer or braille display by default and somehow these are not loading. Also, when trying to install new add-ons, if NVDA sees the add-on is incompatible, it’ll prompt a warning about it.

 

Prior to this change, you can install add-ons on any NVDA release (including upcoming 2018.4), and it was up to add-ons to use features provided by a given NVDA release. This meant really old add-ons could be installed, and if not optimized for recent NVDA releases, the add-on would not work as intended, and in some cases, fail to run outright. Some add-ons do have specific NVDA version requirements, but not all add-ons take advantage of this recommendation.

 

There are several reasons for the change as described above:

 

  1. Python 3 transition: as some of you (I think, at this point, more people) may know, NV Access and several developers (including I) are researching possible roadblocks to Python 3 transition, and I’m maintaining an actual Python 3 version of NVDA for testing purposes. Given massive differences between Python 2 and 3, it was felt to place add-on compatibility checks in place so you won’t install add-ons written in Python 2 on a Python 3 version of NVDA. This is one of the reasons for adding minimum NVDA version checks for add-ons if appropriate. As of today (December 8, 2018), at least three add-ons are Python 3 ready (thus will require newer NVDA versions in the future), and I expect that number to grow significantly in the next few months; the three compatible add-ons are Resource Monitor, SystrayList, and Windows 10 App Essentials, with StationPlaylist Studio to be added to this list in January 2019.
  2. Various internal work planned for the future: these include projects such as speech refactor (changing internals behind NVDA’s speech functionality) and such that will cause some add-ons to fail to work as advertised.

 

The new compatibility flags are:

 

  • minimumNVDAVersion: specifies minimum version of NVDA the add-on is compatible with.
  • lastTestedNVDAVersion: latest compatible NVDA version for the add-on.

 

These manifest keys are optional for now; in 2019, they will become mandatory for ALL add-ons. I would go so far as say that they are MANDATORY from now on, especially if you need to test your add-ons in alpha snapshots and intend to produce a Python 3 version of your add-ons.

 

As of December 8, 2018, only several add-ons hosted on community add-ons website (addons.nvda-project.org) are truly future-proof (compatibility flags are present). The good news is that add-on authors do understand the impact this change will have on their add-ons and some have begun updating their add-ons to add compatibility flags; others plan to add changes once 2019.1 enters beta testing phase (based on past conversations), while the community lost contact with authors of some add-ons (some of which are popular) and their add-ons will be flagged as incompatible unless updates are released.

 

The following add-ons are NVDA 2019.1 compatible and thus won’t cause NVDA to flag them as incompatible:

 

  • Add-on Updater
  • Easy Table Navigator
  • Enhanced Touch Gestures
  • Focus Highlight
  • Golden Cursor
  • GoldWave
  • ObjPad
  • Object Location Tones
  • Resource Monitor
  • StationPlaylist Studio
  • SystrayList
  • Unicode Braille Input
  • Virtual Review
  • Windows 10 App Essentials
  • And possibly more.

 

For add-ons not listed:

 

  • For users: please contact authors of add-ons you’re using and ask for their thoughts and plans for add-on compatibility flags and other future work (see below for words about my add-ons).
  • For developers: please think about the impact of this change and update your add-ons. I don’t expect all add-ons to be made compatible by the time 2019.1 stable version (or release candidate) is released, but at least for popular ones, please have your add-ons made compatible by the time 2019.1 beta 1 shows up. Also, I advise setting last tested version to 2019.2 so you can have plenty of time modernizing add-ons.

 

Notes for users of my add-ons or add-ons that’ll be reviewed by me:

 

  • For users: I expect all my add-ons (at least ones currently under active support) to be made Python 3 ready no later than March 2019. As far as last tested version flag is concerned, I’ll try my best to target later NVDA releases (for example, if using an add-on in NVDA 2019.1, the compatibility flag will indicate support for at least NvDA 2019.3) so you won’t have to worry about compatibility flag problems for a long time; compatibility flags (at least last tested version flag) will be updated once or twice a year.
  • For add-ons to be reviewed: I will look for compatibility flags (as part of user experience portion of basic review) starting from February 2019; other add-on reviewers may or may not look for these flags.
  • For Add-on Updater users: I will start enforcing add-on compatibility flags from version 19.03; that is, Add-on Updater will refuse to install add-on updates if they do not specify at least last tested version flag to align with NVDA 2019.1 behavior.

 

Thank you.

Cheers,

Joseph


 

Hi,

Yes, I and another NVDA developer wrote messages concerning this to add-on authors.

By the way, one more thing: I’ll release patches for most of the add-ons I’m maintaining (resource Monitor and StationPlaylist, for instance) around Christmas to extend last tested NVDA version flag to 2019.3. The only exception will be Unicode Braille Input, which is no longer maintained by me.

Cheers,

Joseph

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of David Goldfield
Sent: Friday, December 7, 2018 9:44 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Important notice: a note or two about future compatibility of add-ons on community add-ons website and elsewhere

 

Joseph,

Thank you for alerting us to this situation. I am somewhat concerned as I do use some third-party add-ons not hosted on the community add-ons page but which are well-known and legal. I'm wondering if the developers of these add-ons have been informed about this change? Specifically, I use the Code Factory Eloquence and Vocalizer add-on, Acapela voices, Dictation Bridge and NVDA Remote. I also hope that Clipspeak and Clip Contents Designer will be updated but I realize these are not your apps.

Thank you again.

 

David Goldfield, Assistive Technology Specialist WWW.David-Goldfield.Com

On 12/8/2018 12:30 AM, Joseph Lee wrote:

Dear NVDA community,

 

This is Joseph Lee, one of the code contributors to NVDA screen reader project and a reviewer of community add-ons. I would like to take this time to update you on what’s been happening in regards to future compatibility of add-ons hosted on various websites, as well as rationale for compatibility notices you’re seeing from recent NVDA development releases (chiefly on alpha channel).

 

As of December 6, 2018, NVDA 2019.1 alpha snapshots (build 16382 onwards) will prompt you to check compatibility of various add-ons when you’re installing snapshots. This is because NVDA will now check if any of your add-ons are compatible with it by looking at two new manifest keys. These add-on manifest keys will tell NVDA if a given add-on is compatible with latest NVDA release, as well as providing a minimum compatible NVDA version if specified. After installing that alpha build and beyond, if NVDA detects one or more add-ons are not compatible, it will present a dialog at start up asking you to check which add-ons you still wish to use despite them being flagged as incompatible. This will be noticeable if you are using a third-party speech synthesizer or braille display by default and somehow these are not loading. Also, when trying to install new add-ons, if NVDA sees the add-on is incompatible, it’ll prompt a warning about it.

 

Prior to this change, you can install add-ons on any NVDA release (including upcoming 2018.4), and it was up to add-ons to use features provided by a given NVDA release. This meant really old add-ons could be installed, and if not optimized for recent NVDA releases, the add-on would not work as intended, and in some cases, fail to run outright. Some add-ons do have specific NVDA version requirements, but not all add-ons take advantage of this recommendation.

 

There are several reasons for the change as described above:

 

  1. Python 3 transition: as some of you (I think, at this point, more people) may know, NV Access and several developers (including I) are researching possible roadblocks to Python 3 transition, and I’m maintaining an actual Python 3 version of NVDA for testing purposes. Given massive differences between Python 2 and 3, it was felt to place add-on compatibility checks in place so you won’t install add-ons written in Python 2 on a Python 3 version of NVDA. This is one of the reasons for adding minimum NVDA version checks for add-ons if appropriate. As of today (December 8, 2018), at least three add-ons are Python 3 ready (thus will require newer NVDA versions in the future), and I expect that number to grow significantly in the next few months; the three compatible add-ons are Resource Monitor, SystrayList, and Windows 10 App Essentials, with StationPlaylist Studio to be added to this list in January 2019.
  2. Various internal work planned for the future: these include projects such as speech refactor (changing internals behind NVDA’s speech functionality) and such that will cause some add-ons to fail to work as advertised.

 

The new compatibility flags are:

 

  • minimumNVDAVersion: specifies minimum version of NVDA the add-on is compatible with.
  • lastTestedNVDAVersion: latest compatible NVDA version for the add-on.

 

These manifest keys are optional for now; in 2019, they will become mandatory for ALL add-ons. I would go so far as say that they are MANDATORY from now on, especially if you need to test your add-ons in alpha snapshots and intend to produce a Python 3 version of your add-ons.

 

As of December 8, 2018, only several add-ons hosted on community add-ons website (addons.nvda-project.org) are truly future-proof (compatibility flags are present). The good news is that add-on authors do understand the impact this change will have on their add-ons and some have begun updating their add-ons to add compatibility flags; others plan to add changes once 2019.1 enters beta testing phase (based on past conversations), while the community lost contact with authors of some add-ons (some of which are popular) and their add-ons will be flagged as incompatible unless updates are released.

 

The following add-ons are NVDA 2019.1 compatible and thus won’t cause NVDA to flag them as incompatible:

 

  • Add-on Updater
  • Easy Table Navigator
  • Enhanced Touch Gestures
  • Focus Highlight
  • Golden Cursor
  • GoldWave
  • ObjPad
  • Object Location Tones
  • Resource Monitor
  • StationPlaylist Studio
  • SystrayList
  • Unicode Braille Input
  • Virtual Review
  • Windows 10 App Essentials
  • And possibly more.

 

For add-ons not listed:

 

  • For users: please contact authors of add-ons you’re using and ask for their thoughts and plans for add-on compatibility flags and other future work (see below for words about my add-ons).
  • For developers: please think about the impact of this change and update your add-ons. I don’t expect all add-ons to be made compatible by the time 2019.1 stable version (or release candidate) is released, but at least for popular ones, please have your add-ons made compatible by the time 2019.1 beta 1 shows up. Also, I advise setting last tested version to 2019.2 so you can have plenty of time modernizing add-ons.

 

Notes for users of my add-ons or add-ons that’ll be reviewed by me:

 

  • For users: I expect all my add-ons (at least ones currently under active support) to be made Python 3 ready no later than March 2019. As far as last tested version flag is concerned, I’ll try my best to target later NVDA releases (for example, if using an add-on in NVDA 2019.1, the compatibility flag will indicate support for at least NvDA 2019.3) so you won’t have to worry about compatibility flag problems for a long time; compatibility flags (at least last tested version flag) will be updated once or twice a year.
  • For add-ons to be reviewed: I will look for compatibility flags (as part of user experience portion of basic review) starting from February 2019; other add-on reviewers may or may not look for these flags.
  • For Add-on Updater users: I will start enforcing add-on compatibility flags from version 19.03; that is, Add-on Updater will refuse to install add-on updates if they do not specify at least last tested version flag to align with NVDA 2019.1 behavior.

 

Thank you.

Cheers,

Joseph


Devin Prater
 

Thanks so much for all this information. I hope that the author of Braille Extender updates that add-on, as it is one of the most useful admins to me.

On Dec 7, 2018, at 11:50 PM, Joseph Lee <joseph.lee22590@...> wrote:

Hi,
Yes, I and another NVDA developer wrote messages concerning this to add-on authors.
By the way, one more thing: I’ll release patches for most of the add-ons I’m maintaining (resource Monitor and StationPlaylist, for instance) around Christmas to extend last tested NVDA version flag to 2019.3. The only exception will be Unicode Braille Input, which is no longer maintained by me.
Cheers,
Joseph
 
From: nvda@nvda.groups.io<nvda@nvda.groups.io> On Behalf Of David Goldfield
Sent: Friday, December 7, 2018 9:44 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Important notice: a note or two about future compatibility of add-ons on community add-ons website and elsewhere
 

Joseph,

Thank you for alerting us to this situation. I am somewhat concerned as I do use some third-party add-ons not hosted on the community add-ons page but which are well-known and legal. I'm wondering if the developers of these add-ons have been informed about this change? Specifically, I use the Code Factory Eloquence and Vocalizer add-on, Acapela voices, Dictation Bridge and NVDA Remote. I also hope that Clipspeak and Clip Contents Designer will be updated but I realize these are not your apps.

Thank you again.

 

David Goldfield, Assistive Technology Specialist WWW.David-Goldfield.Com
On 12/8/2018 12:30 AM, Joseph Lee wrote:
Dear NVDA community,
 
This is Joseph Lee, one of the code contributors to NVDA screen reader project and a reviewer of community add-ons. I would like to take this time to update you on what’s been happening in regards to future compatibility of add-ons hosted on various websites, as well as rationale for compatibility notices you’re seeing from recent NVDA development releases (chiefly on alpha channel).
 
As of December 6, 2018, NVDA 2019.1 alpha snapshots (build 16382 onwards) will prompt you to check compatibility of various add-ons when you’re installing snapshots. This is because NVDA will now check if any of your add-ons are compatible with it by looking at two new manifest keys. These add-on manifest keys will tell NVDA if a given add-on is compatible with latest NVDA release, as well as providing a minimum compatible NVDA version if specified. After installing that alpha build and beyond, if NVDA detects one or more add-ons are not compatible, it will present a dialog at start up asking you to check which add-ons you still wish to use despite them being flagged as incompatible. This will be noticeable if you are using a third-party speech synthesizer or braille display by default and somehow these are not loading. Also, when trying to install new add-ons, if NVDA sees the add-on is incompatible, it’ll prompt a warning about it.
 
Prior to this change, you can install add-ons on any NVDA release (including upcoming 2018.4), and it was up to add-ons to use features provided by a given NVDA release. This meant really old add-ons could be installed, and if not optimized for recent NVDA releases, the add-on would not work as intended, and in some cases, fail to run outright. Some add-ons do have specific NVDA version requirements, but not all add-ons take advantage of this recommendation.
 
There are several reasons for the change as described above:
 
  1. Python 3 transition: as some of you (I think, at this point, more people) may know, NV Access and several developers (including I) are researching possible roadblocks to Python 3 transition, and I’m maintaining an actual Python 3 version of NVDA for testing purposes. Given massive differences between Python 2 and 3, it was felt to place add-on compatibility checks in place so you won’t install add-ons written in Python 2 on a Python 3 version of NVDA. This is one of the reasons for adding minimum NVDA version checks for add-ons if appropriate. As of today (December 8, 2018), at least three add-ons are Python 3 ready (thus will require newer NVDA versions in the future), and I expect that number to grow significantly in the next few months; the three compatible add-ons are Resource Monitor, SystrayList, and Windows 10 App Essentials, with StationPlaylist Studio to be added to this list in January 2019. 
  2. Various internal work planned for the future: these include projects such as speech refactor (changing internals behind NVDA’s speech functionality) and such that will cause some add-ons to fail to work as advertised. 
 
The new compatibility flags are:
 
  • minimumNVDAVersion: specifies minimum version of NVDA the add-on is compatible with. 
  • lastTestedNVDAVersion: latest compatible NVDA version for the add-on. 
 
These manifest keys are optional for now; in 2019, they will become mandatory for ALL add-ons. I would go so far as say that they are MANDATORY from now on, especially if you need to test your add-ons in alpha snapshots and intend to produce a Python 3 version of your add-ons.
 
As of December 8, 2018, only several add-ons hosted on community add-ons website (addons.nvda-project.org) are truly future-proof (compatibility flags are present). The good news is that add-on authors do understand the impact this change will have on their add-ons and some have begun updating their add-ons to add compatibility flags; others plan to add changes once 2019.1 enters beta testing phase (based on past conversations), while the community lost contact with authors of some add-ons (some of which are popular) and their add-ons will be flagged as incompatible unless updates are released.
 
The following add-ons are NVDA 2019.1 compatible and thus won’t cause NVDA to flag them as incompatible:
 
  • Add-on Updater 
  • Easy Table Navigator 
  • Enhanced Touch Gestures 
  • Focus Highlight 
  • Golden Cursor 
  • GoldWave 
  • ObjPad 
  • Object Location Tones 
  • Resource Monitor 
  • StationPlaylist Studio 
  • SystrayList 
  • Unicode Braille Input 
  • Virtual Review 
  • Windows 10 App Essentials 
  • And possibly more. 
 
For add-ons not listed:
 
  • For users: please contact authors of add-ons you’re using and ask for their thoughts and plans for add-on compatibility flags and other future work (see below for words about my add-ons). 
  • For developers: please think about the impact of this change and update your add-ons. I don’t expect all add-ons to be made compatible by the time 2019.1 stable version (or release candidate) is released, but at least for popular ones, please have your add-ons made compatible by the time 2019.1 beta 1 shows up. Also, I advise setting last tested version to 2019.2 so you can have plenty of time modernizing add-ons. 
 
Notes for users of my add-ons or add-ons that’ll be reviewed by me:
 
  • For users: I expect all my add-ons (at least ones currently under active support) to be made Python 3 ready no later than March 2019. As far as last tested version flag is concerned, I’ll try my best to target later NVDA releases (for example, if using an add-on in NVDA 2019.1, the compatibility flag will indicate support for at least NvDA 2019.3) so you won’t have to worry about compatibility flag problems for a long time; compatibility flags (at least last tested version flag) will be updated once or twice a year. 
  • For add-ons to be reviewed: I will look for compatibility flags (as part of user experience portion of basic review) starting from February 2019; other add-on reviewers may or may not look for these flags. 
  • For Add-on Updater users: I will start enforcing add-on compatibility flags from version 19.03; that is, Add-on Updater will refuse to install add-on updates if they do not specify at least last tested version flag to align with NVDA 2019.1 behavior. 
 
Thank you.
Cheers,
Joseph



Tyler Spivey
 

So far, the user experience for this is really bad. I had to manually
tweak 40+ addons three times during two updates.
I hope I don't have to deal with this every time I update my snapshot.

On 12/7/2018 10:45 PM, Devin Prater wrote:
Thanks so much for all this information. I hope that the author of
Braille Extender updates that add-on, as it is one of the most useful
admins to me.

On Dec 7, 2018, at 11:50 PM, Joseph Lee <joseph.lee22590@gmail.com
<mailto:joseph.lee22590@gmail.com>> wrote:

Hi,
Yes, I and another NVDA developer wrote messages concerning this to
add-on authors.
By the way, one more thing: I’ll release patches for most of the
add-ons I’m maintaining (resource Monitor and StationPlaylist, for
instance) around Christmas to extend last tested NVDA version flag to
2019.3. The only exception will be Unicode Braille Input, which is no
longer maintained by me.
Cheers,
Joseph
 
*From:* nvda@nvda.groups.io
<mailto:nvda@nvda.groups.io><nvda@nvda.groups.io
<mailto:nvda@nvda.groups.io>> *On Behalf Of *David Goldfield
*Sent:* Friday, December 7, 2018 9:44 PM
*To:* nvda@nvda.groups.io <mailto:nvda@nvda.groups.io>
*Subject:* Re: [nvda] Important notice: a note or two about future
compatibility of add-ons on community add-ons website and elsewhere
 

Joseph,

Thank you for alerting us to this situation. I am somewhat concerned
as I do use some third-party add-ons not hosted on the community
add-ons page but which are well-known and legal. I'm wondering if the
developers of these add-ons have been informed about this change?
Specifically, I use the Code Factory Eloquence and Vocalizer add-on,
Acapela voices, Dictation Bridge and NVDA Remote. I also hope that
Clipspeak and Clip Contents Designer will be updated but I realize
these are not your apps.

Thank you again.

 

David Goldfield, Assistive Technology
Specialist WWW.David-Goldfield.Com <http://www.david-goldfield.com/>
On 12/8/2018 12:30 AM, Joseph Lee wrote:

Dear NVDA community,
 
This is Joseph Lee, one of the code contributors to NVDA screen
reader project and a reviewer of community add-ons. I would like
to take this time to update you on what’s been happening in
regards to future compatibility of add-ons hosted on various
websites, as well as rationale for compatibility notices you’re
seeing from recent NVDA development releases (chiefly on alpha
channel).
 
As of December 6, 2018, NVDA 2019.1 alpha snapshots (build 16382
onwards) will prompt you to check compatibility of various add-ons
when you’re installing snapshots. This is because NVDA will now
check if any of your add-ons are compatible with it by looking at
two new manifest keys. These add-on manifest keys will tell NVDA
if a given add-on is compatible with latest NVDA release, as well
as providing a minimum compatible NVDA version if specified. After
installing that alpha build and beyond, if NVDA detects one or
more add-ons are not compatible, it will present a dialog at start
up asking you to check which add-ons you still wish to use despite
them being flagged as incompatible. This will be noticeable if you
are using a third-party speech synthesizer or braille display by
default and somehow these are not loading. Also, when trying to
install new add-ons, if NVDA sees the add-on is incompatible,
it’ll prompt a warning about it.
 
Prior to this change, you can install add-ons on any NVDA release
(including upcoming 2018.4), and it was up to add-ons to use
features provided by a given NVDA release. This meant really old
add-ons could be installed, and if not optimized for recent NVDA
releases, the add-on would not work as intended, and in some
cases, fail to run outright. Some add-ons do have specific NVDA
version requirements, but not all add-ons take advantage of this
recommendation.
 
There are several reasons for the change as described above:
 

1. Python 3 transition: as some of you (I think, at this point,
more people) may know, NV Access and several developers
(including I) are researching possible roadblocks to Python 3
transition, and I’m maintaining an actual Python 3 version of
NVDA for testing purposes. Given massive differences between
Python 2 and 3, it was felt to place add-on compatibility
checks in place so you won’t install add-ons written in Python
2 on a Python 3 version of NVDA. This is one of the reasons
for adding minimum NVDA version checks for add-ons if
appropriate. As of today (December 8, 2018), at least three
add-ons are Python 3 ready (thus will require newer NVDA
versions in the future), and I expect that number to grow
significantly in the next few months; the three compatible
add-ons are Resource Monitor, SystrayList, and Windows 10 App
Essentials, with StationPlaylist Studio to be added to this
list in January 2019. 
2. Various internal work planned for the future: these include
projects such as speech refactor (changing internals behind
NVDA’s speech functionality) and such that will cause some
add-ons to fail to work as advertised. 

 
The new compatibility flags are:
 

* minimumNVDAVersion: specifies minimum version of NVDA the
add-on is compatible with. 
* lastTestedNVDAVersion: latest compatible NVDA version for the
add-on. 

 
These manifest keys are optional for now; in 2019, they will
become mandatory for ALL add-ons. I would go so far as say that
they are MANDATORY from now on, especially if you need to test
your add-ons in alpha snapshots and intend to produce a Python 3
version of your add-ons.
 
As of December 8, 2018, only several add-ons hosted on community
add-ons website (addons.nvda-project.org
<http://addons.nvda-project.org/>) are truly future-proof
(compatibility flags are present). The good news is that add-on
authors do understand the impact this change will have on their
add-ons and some have begun updating their add-ons to add
compatibility flags; others plan to add changes once 2019.1 enters
beta testing phase (based on past conversations), while the
community lost contact with authors of some add-ons (some of which
are popular) and their add-ons will be flagged as incompatible
unless updates are released.
 
The following add-ons are NVDA 2019.1 compatible and thus won’t
cause NVDA to flag them as incompatible:
 

* Add-on Updater 
* Easy Table Navigator 
* Enhanced Touch Gestures 
* Focus Highlight 
* Golden Cursor 
* GoldWave 
* ObjPad 
* Object Location Tones 
* Resource Monitor 
* StationPlaylist Studio 
* SystrayList 
* Unicode Braille Input 
* Virtual Review 
* Windows 10 App Essentials 
* And possibly more. 

 
For add-ons not listed:
 

* For users: please contact authors of add-ons you’re using and
ask for their thoughts and plans for add-on compatibility
flags and other future work (see below for words about my
add-ons). 
* For developers: please think about the impact of this change
and update your add-ons. I don’t expect all add-ons to be made
compatible by the time 2019.1 stable version (or release
candidate) is released, but at least for popular ones, please
have your add-ons made compatible by the time 2019.1 beta 1
shows up. Also, I advise setting last tested version to 2019.2
so you can have plenty of time modernizing add-ons. 

 
Notes for users of my add-ons or add-ons that’ll be reviewed by me:
 

* For users: I expect all my add-ons (at least ones currently
under active support) to be made Python 3 ready no later than
March 2019. As far as last tested version flag is concerned,
I’ll try my best to target later NVDA releases (for example,
if using an add-on in NVDA 2019.1, the compatibility flag will
indicate support for at least NvDA 2019.3) so you won’t have
to worry about compatibility flag problems for a long time;
compatibility flags (at least last tested version flag) will
be updated once or twice a year. 
* For add-ons to be reviewed: I will look for compatibility
flags (as part of user experience portion of basic review)
starting from February 2019; other add-on reviewers may or may
not look for these flags. 
* For Add-on Updater users: I will start enforcing add-on
compatibility flags from version 19.03; that is, Add-on
Updater will refuse to install add-on updates if they do not
specify at least last tested version flag to align with NVDA
2019.1 behavior. 

 
Thank you.
Cheers,
Joseph


Brian's Mail list account <bglists@...>
 

Right then. At the moment it is the majority of add ons that are incompatible. I am thinking this is going to be a show stopper for many as included in this list are toolbar Explorer, Application dictionary, Extended winamp say prompts for copy etc, The 3D sounds add on, Pico synth, Speech player in Espeak, open link with an add on that is really very useful.
MP3 Direct cut and sundry others I use all the time.
I may in the end have to stop using alphas and intended the later versions of NVDA unless all this work done by people can be either fixed or nvda rethinks its Python 3 migration.
Brian

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

----- Original Message -----
From: "Joseph Lee" <joseph.lee22590@gmail.com>
To: "'NVDA screen reader development'" <nvda-devel@lists.sourceforge.net>
Sent: Saturday, December 08, 2018 5:30 AM
Subject: [nvda] Important notice: a note or two about future compatibility of add-ons on community add-ons website and elsewhere


Dear NVDA community,



This is Joseph Lee, one of the code contributors to NVDA screen reader
project and a reviewer of community add-ons. I would like to take this time
to update you on what's been happening in regards to future compatibility of
add-ons hosted on various websites, as well as rationale for compatibility
notices you're seeing from recent NVDA development releases (chiefly on
alpha channel).



As of December 6, 2018, NVDA 2019.1 alpha snapshots (build 16382 onwards)
will prompt you to check compatibility of various add-ons when you're
installing snapshots. This is because NVDA will now check if any of your
add-ons are compatible with it by looking at two new manifest keys. These
add-on manifest keys will tell NVDA if a given add-on is compatible with
latest NVDA release, as well as providing a minimum compatible NVDA version
if specified. After installing that alpha build and beyond, if NVDA detects
one or more add-ons are not compatible, it will present a dialog at start up
asking you to check which add-ons you still wish to use despite them being
flagged as incompatible. This will be noticeable if you are using a
third-party speech synthesizer or braille display by default and somehow
these are not loading. Also, when trying to install new add-ons, if NVDA
sees the add-on is incompatible, it'll prompt a warning about it.



Prior to this change, you can install add-ons on any NVDA release (including
upcoming 2018.4), and it was up to add-ons to use features provided by a
given NVDA release. This meant really old add-ons could be installed, and if
not optimized for recent NVDA releases, the add-on would not work as
intended, and in some cases, fail to run outright. Some add-ons do have
specific NVDA version requirements, but not all add-ons take advantage of
this recommendation.



There are several reasons for the change as described above:



1. Python 3 transition: as some of you (I think, at this point, more
people) may know, NV Access and several developers (including I) are
researching possible roadblocks to Python 3 transition, and I'm maintaining
an actual Python 3 version of NVDA for testing purposes. Given massive
differences between Python 2 and 3, it was felt to place add-on
compatibility checks in place so you won't install add-ons written in Python
2 on a Python 3 version of NVDA. This is one of the reasons for adding
minimum NVDA version checks for add-ons if appropriate. As of today
(December 8, 2018), at least three add-ons are Python 3 ready (thus will
require newer NVDA versions in the future), and I expect that number to grow
significantly in the next few months; the three compatible add-ons are
Resource Monitor, SystrayList, and Windows 10 App Essentials, with
StationPlaylist Studio to be added to this list in January 2019.
2. Various internal work planned for the future: these include projects
such as speech refactor (changing internals behind NVDA's speech
functionality) and such that will cause some add-ons to fail to work as
advertised.



The new compatibility flags are:



* minimumNVDAVersion: specifies minimum version of NVDA the add-on is
compatible with.
* lastTestedNVDAVersion: latest compatible NVDA version for the
add-on.



These manifest keys are optional for now; in 2019, they will become
mandatory for ALL add-ons. I would go so far as say that they are MANDATORY
from now on, especially if you need to test your add-ons in alpha snapshots
and intend to produce a Python 3 version of your add-ons.



As of December 8, 2018, only several add-ons hosted on community add-ons
website (addons.nvda-project.org) are truly future-proof (compatibility
flags are present). The good news is that add-on authors do understand the
impact this change will have on their add-ons and some have begun updating
their add-ons to add compatibility flags; others plan to add changes once
2019.1 enters beta testing phase (based on past conversations), while the
community lost contact with authors of some add-ons (some of which are
popular) and their add-ons will be flagged as incompatible unless updates
are released.



The following add-ons are NVDA 2019.1 compatible and thus won't cause NVDA
to flag them as incompatible:



* Add-on Updater
* Easy Table Navigator
* Enhanced Touch Gestures
* Focus Highlight
* Golden Cursor
* GoldWave
* ObjPad
* Object Location Tones
* Resource Monitor
* StationPlaylist Studio
* SystrayList
* Unicode Braille Input
* Virtual Review
* Windows 10 App Essentials
* And possibly more.



For add-ons not listed:



* For users: please contact authors of add-ons you're using and ask
for their thoughts and plans for add-on compatibility flags and other future
work (see below for words about my add-ons).
* For developers: please think about the impact of this change and
update your add-ons. I don't expect all add-ons to be made compatible by the
time 2019.1 stable version (or release candidate) is released, but at least
for popular ones, please have your add-ons made compatible by the time
2019.1 beta 1 shows up. Also, I advise setting last tested version to 2019.2
so you can have plenty of time modernizing add-ons.



Notes for users of my add-ons or add-ons that'll be reviewed by me:



* For users: I expect all my add-ons (at least ones currently under
active support) to be made Python 3 ready no later than March 2019. As far
as last tested version flag is concerned, I'll try my best to target later
NVDA releases (for example, if using an add-on in NVDA 2019.1, the
compatibility flag will indicate support for at least NvDA 2019.3) so you
won't have to worry about compatibility flag problems for a long time;
compatibility flags (at least last tested version flag) will be updated once
or twice a year.
* For add-ons to be reviewed: I will look for compatibility flags (as
part of user experience portion of basic review) starting from February
2019; other add-on reviewers may or may not look for these flags.
* For Add-on Updater users: I will start enforcing add-on
compatibility flags from version 19.03; that is, Add-on Updater will refuse
to install add-on updates if they do not specify at least last tested
version flag to align with NVDA 2019.1 behavior.



Thank you.

Cheers,

Joseph




Mobeen Iqbal
 

I would be inclined to agree. The add-ons shouldn't be prevented from running and the user should be given the option to suppress notifications about compatibility until they upgrade to the next major release, then be given the option to dismiss the notice again until the next upgrade and so on. Yes there is a risk that the existing add-ons could stop working and that they should be updated, but an example is the dolphin sam add-on which some users use because they can understand dolphin's voices better. They have hearing difficulties. I am going to see if the developer can be located and the add-on updated, but users won't be happy if the add-ons are prevented from running and their equipment stops working. I know that prevention isn't on the cards so much but developers need to be careful so people don't stop using NVDA.


Mo.

On 08/12/2018 11:12, Brian's Mail list account via Groups.Io wrote:
Right then. At the moment it is the majority of add ons that are incompatible. I am thinking this is going to be a show stopper for many as included in this list are toolbar Explorer, Application dictionary, Extended winamp  say  prompts for copy etc, The 3D sounds add on, Pico synth, Speech player in Espeak,   open link with an add on that is really very useful.
MP3 Direct cut  and sundry others I use all the time.
I may in the end have to stop using alphas and intended the later versions of NVDA unless all this work done by people can be either fixed or nvda rethinks its Python 3 migration.
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
----- Original Message ----- From: "Joseph Lee" <joseph.lee22590@gmail.com>
To: "'NVDA screen reader development'" <nvda-devel@lists.sourceforge.net>
Sent: Saturday, December 08, 2018 5:30 AM
Subject: [nvda] Important notice: a note or two about future compatibility of add-ons on community add-ons website and elsewhere


Dear NVDA community,



This is Joseph Lee, one of the code contributors to NVDA screen reader
project and a reviewer of community add-ons. I would like to take this time
to update you on what's been happening in regards to future compatibility of
add-ons hosted on various websites, as well as rationale for compatibility
notices you're seeing from recent NVDA development releases (chiefly on
alpha channel).



As of December 6, 2018, NVDA 2019.1 alpha snapshots (build 16382 onwards)
will prompt you to check compatibility of various add-ons when you're
installing snapshots. This is because NVDA will now check if any of your
add-ons are compatible with it by looking at two new manifest keys. These
add-on manifest keys will tell NVDA if a given add-on is compatible with
latest NVDA release, as well as providing a minimum compatible NVDA version
if specified. After installing that alpha build and beyond, if NVDA detects
one or more add-ons are not compatible, it will present a dialog at start up
asking you to check which add-ons you still wish to use despite them being
flagged as incompatible. This will be noticeable if you are using a
third-party speech synthesizer or braille display by default and somehow
these are not loading. Also, when trying to install new add-ons, if NVDA
sees the add-on is incompatible, it'll prompt a warning about it.



Prior to this change, you can install add-ons on any NVDA release (including
upcoming 2018.4), and it was up to add-ons to use features provided by a
given NVDA release. This meant really old add-ons could be installed, and if
not optimized for recent NVDA releases, the add-on would not work as
intended, and in some cases, fail to run outright. Some add-ons do have
specific NVDA version requirements, but not all add-ons take advantage of
this recommendation.



There are several reasons for the change as described above:



1. Python 3 transition: as some of you (I think, at this point, more
people) may know, NV Access and several developers (including I) are
researching possible roadblocks to Python 3 transition, and I'm maintaining
an actual Python 3 version of NVDA for testing purposes. Given massive
differences between Python 2 and 3, it was felt to place add-on
compatibility checks in place so you won't install add-ons written in Python
2 on a Python 3 version of NVDA. This is one of the reasons for adding
minimum NVDA version checks for add-ons if appropriate. As of today
(December 8, 2018), at least three add-ons are Python 3 ready (thus will
require newer NVDA versions in the future), and I expect that number to grow
significantly in the next few months; the three compatible add-ons are
Resource Monitor, SystrayList, and Windows 10 App Essentials, with
StationPlaylist Studio to be added to this list in January 2019.
2. Various internal work planned for the future: these include projects
such as speech refactor (changing internals behind NVDA's speech
functionality) and such that will cause some add-ons to fail to work as
advertised.



The new compatibility flags are:



* minimumNVDAVersion: specifies minimum version of NVDA the add-on is
compatible with.
* lastTestedNVDAVersion: latest compatible NVDA version for the
add-on.



These manifest keys are optional for now; in 2019, they will become
mandatory for ALL add-ons. I would go so far as say that they are MANDATORY
from now on, especially if you need to test your add-ons in alpha snapshots
and intend to produce a Python 3 version of your add-ons.



As of December 8, 2018, only several add-ons hosted on community add-ons
website (addons.nvda-project.org) are truly future-proof (compatibility
flags are present). The good news is that add-on authors do understand the
impact this change will have on their add-ons and some have begun updating
their add-ons to add compatibility flags; others plan to add changes once
2019.1 enters beta testing phase (based on past conversations), while the
community lost contact with authors of some add-ons (some of which are
popular) and their add-ons will be flagged as incompatible unless updates
are released.



The following add-ons are NVDA 2019.1 compatible and thus won't cause NVDA
to flag them as incompatible:



* Add-on Updater
* Easy Table Navigator
* Enhanced Touch Gestures
* Focus Highlight
* Golden Cursor
* GoldWave
* ObjPad
* Object Location Tones
* Resource Monitor
* StationPlaylist Studio
* SystrayList
* Unicode Braille Input
* Virtual Review
* Windows 10 App Essentials
* And possibly more.



For add-ons not listed:



* For users: please contact authors of add-ons you're using and ask
for their thoughts and plans for add-on compatibility flags and other future
work (see below for words about my add-ons).
* For developers: please think about the impact of this change and
update your add-ons. I don't expect all add-ons to be made compatible by the
time 2019.1 stable version (or release candidate) is released, but at least
for popular ones, please have your add-ons made compatible by the time
2019.1 beta 1 shows up. Also, I advise setting last tested version to 2019.2
so you can have plenty of time modernizing add-ons.



Notes for users of my add-ons or add-ons that'll be reviewed by me:



* For users: I expect all my add-ons (at least ones currently under
active support) to be made Python 3 ready no later than March 2019. As far
as last tested version flag is concerned, I'll try my best to target later
NVDA releases (for example, if using an add-on in NVDA 2019.1, the
compatibility flag will indicate support for at least NvDA 2019.3) so you
won't have to worry about compatibility flag problems for a long time;
compatibility flags (at least last tested version flag) will be updated once
or twice a year.
* For add-ons to be reviewed: I will look for compatibility flags (as
part of user experience portion of basic review) starting from February
2019; other add-on reviewers may or may not look for these flags.
* For Add-on Updater users: I will start enforcing add-on
compatibility flags from version 19.03; that is, Add-on Updater will refuse
to install add-on updates if they do not specify at least last tested
version flag to align with NVDA 2019.1 behavior.



Thank you.

Cheers,

Joseph






Adriani Botez
 

Hello,

Actually people can stay to NVDA 2018.4 for some months until we manage to contact all developers and discuss what they have to do. It is like at that time when support for Windows XP has been dropped. Technology moves forward and we must keep in touch with it if we want to become more advanced in what we do. In this case, there are thousants of alternatives for speech synthesizers. As Mick already pointed out, NV Access will certainly push hard so that suppliers of sythesizers will update their engines as fast as possible. And as far as old add-ons are concerned (i.e. extended winamp etc.) it is very simple: if developers of those add-ons do not care about them then users should look for other pieces of software which is more modern and commonly used. For example VLC player or other music organizers. Winamp is not the only player in the world. And if the developer did not develop his or der add-on further then it is somehow clear that the developer himself gave up using Winamp or so. This transition period will be maybe half a year long or maybe one year. And I am prety sure that until then every add-on will be compatible with NVDA. Even the Winamp add-on.

In my opinion, add-ons must work in line with NVDA. Not NVDA in line with the add-ons. This is also valid in case of Jaws or other screen readers. Because we have here the following hierarchy from top to bottom: Accessibility API / scree reader / add-ons. And since the accessibility APIs are updated regularly, screen readers must be updated as well. In turn, add-ons must be updated either.

Best
Adriani





-----Ursprüngliche Nachricht-----
Von: nvda@nvda.groups.io <nvda@nvda.groups.io> Im Auftrag von Mobeen Iqbal
Gesendet: Samstag, 8. Dezember 2018 12:25
An: nvda@nvda.groups.io
Betreff: Re: [nvda] Important notice: a note or two about future compatibility of add-ons on community add-ons website and elsewhere

I would be inclined to agree. The add-ons shouldn't be prevented from running and the user should be given the option to suppress notifications about compatibility until they upgrade to the next major release, then be given the option to dismiss the notice again until the next upgrade and so on. Yes there is a risk that the existing add-ons could stop working and that they should be updated, but an example is the dolphin sam add-on which some users use because they can understand dolphin's voices better. They have hearing difficulties. I am going to see if the developer can be located and the add-on updated, but users won't be happy if the add-ons are prevented from running and their equipment stops working. I know that prevention isn't on the cards so much but developers need to be careful so people don't stop using NVDA.


Mo.

On 08/12/2018 11:12, Brian's Mail list account via Groups.Io wrote:
Right then. At the moment it is the majority of add ons that are
incompatible. I am thinking this is going to be a show stopper for
many as included in this list are toolbar Explorer, Application
dictionary, Extended winamp say prompts for copy etc, The 3D sounds
add on, Pico synth, Speech player in Espeak, open link with an add
on that is really very useful.
MP3 Direct cut and sundry others I use all the time.
I may in the end have to stop using alphas and intended the later
versions of NVDA unless all this work done by people can be either
fixed or nvda rethinks its Python 3 migration.
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
----- Original Message ----- From: "Joseph Lee"
<joseph.lee22590@gmail.com>
To: "'NVDA screen reader development'"
<nvda-devel@lists.sourceforge.net>
Sent: Saturday, December 08, 2018 5:30 AM
Subject: [nvda] Important notice: a note or two about future
compatibility of add-ons on community add-ons website and elsewhere


Dear NVDA community,



This is Joseph Lee, one of the code contributors to NVDA screen
reader project and a reviewer of community add-ons. I would like to
take this time to update you on what's been happening in regards to
future compatibility of add-ons hosted on various websites, as well
as rationale for compatibility notices you're seeing from recent NVDA
development releases (chiefly on alpha channel).



As of December 6, 2018, NVDA 2019.1 alpha snapshots (build 16382
onwards)
will prompt you to check compatibility of various add-ons when you're
installing snapshots. This is because NVDA will now check if any of
your add-ons are compatible with it by looking at two new manifest keys.
These
add-on manifest keys will tell NVDA if a given add-on is compatible
with latest NVDA release, as well as providing a minimum compatible
NVDA version if specified. After installing that alpha build and
beyond, if NVDA detects one or more add-ons are not compatible, it
will present a dialog at start up asking you to check which add-ons
you still wish to use despite them being flagged as incompatible.
This will be noticeable if you are using a third-party speech
synthesizer or braille display by default and somehow these are not
loading. Also, when trying to install new add-ons, if NVDA sees the
add-on is incompatible, it'll prompt a warning about it.



Prior to this change, you can install add-ons on any NVDA release
(including upcoming 2018.4), and it was up to add-ons to use features
provided by a given NVDA release. This meant really old add-ons could
be installed, and if not optimized for recent NVDA releases, the
add-on would not work as intended, and in some cases, fail to run
outright. Some add-ons do have specific NVDA version requirements,
but not all add-ons take advantage of this recommendation.



There are several reasons for the change as described above:



1. Python 3 transition: as some of you (I think, at this point, more
people) may know, NV Access and several developers (including I) are
researching possible roadblocks to Python 3 transition, and I'm
maintaining an actual Python 3 version of NVDA for testing purposes.
Given massive differences between Python 2 and 3, it was felt to
place add-on compatibility checks in place so you won't install
add-ons written in Python
2 on a Python 3 version of NVDA. This is one of the reasons for
adding minimum NVDA version checks for add-ons if appropriate. As of
today (December 8, 2018), at least three add-ons are Python 3 ready
(thus will require newer NVDA versions in the future), and I expect
that number to grow significantly in the next few months; the three
compatible add-ons are Resource Monitor, SystrayList, and Windows 10
App Essentials, with StationPlaylist Studio to be added to this list
in January 2019.
2. Various internal work planned for the future: these include
projects such as speech refactor (changing internals behind NVDA's
speech
functionality) and such that will cause some add-ons to fail to work
as advertised.



The new compatibility flags are:



* minimumNVDAVersion: specifies minimum version of NVDA the add-on is
compatible with.
* lastTestedNVDAVersion: latest compatible NVDA version for the
add-on.



These manifest keys are optional for now; in 2019, they will become
mandatory for ALL add-ons. I would go so far as say that they are
MANDATORY from now on, especially if you need to test your add-ons in
alpha snapshots and intend to produce a Python 3 version of your
add-ons.



As of December 8, 2018, only several add-ons hosted on community
add-ons website (addons.nvda-project.org) are truly future-proof
(compatibility flags are present). The good news is that add-on
authors do understand the impact this change will have on their
add-ons and some have begun updating their add-ons to add
compatibility flags; others plan to add changes once
2019.1 enters beta testing phase (based on past conversations), while
the community lost contact with authors of some add-ons (some of
which are
popular) and their add-ons will be flagged as incompatible unless
updates are released.



The following add-ons are NVDA 2019.1 compatible and thus won't cause
NVDA to flag them as incompatible:



* Add-on Updater
* Easy Table Navigator
* Enhanced Touch Gestures
* Focus Highlight
* Golden Cursor
* GoldWave
* ObjPad
* Object Location Tones
* Resource Monitor
* StationPlaylist Studio
* SystrayList
* Unicode Braille Input
* Virtual Review
* Windows 10 App Essentials
* And possibly more.



For add-ons not listed:



* For users: please contact authors of add-ons you're using and ask
for their thoughts and plans for add-on compatibility flags and other
future
work (see below for words about my add-ons).
* For developers: please think about the impact of this change and
update your add-ons. I don't expect all add-ons to be made compatible
by the
time 2019.1 stable version (or release candidate) is released, but at
least
for popular ones, please have your add-ons made compatible by the time
2019.1 beta 1 shows up. Also, I advise setting last tested version to
2019.2
so you can have plenty of time modernizing add-ons.



Notes for users of my add-ons or add-ons that'll be reviewed by me:



* For users: I expect all my add-ons (at least ones currently under
active support) to be made Python 3 ready no later than March 2019.
As far
as last tested version flag is concerned, I'll try my best to target
later
NVDA releases (for example, if using an add-on in NVDA 2019.1, the
compatibility flag will indicate support for at least NvDA 2019.3) so
you
won't have to worry about compatibility flag problems for a long time;
compatibility flags (at least last tested version flag) will be
updated once
or twice a year.
* For add-ons to be reviewed: I will look for compatibility flags (as
part of user experience portion of basic review) starting from February
2019; other add-on reviewers may or may not look for these flags.
* For Add-on Updater users: I will start enforcing add-on
compatibility flags from version 19.03; that is, Add-on Updater will
refuse
to install add-on updates if they do not specify at least last tested
version flag to align with NVDA 2019.1 behavior.



Thank you.

Cheers,

Joseph







Gene
 

It may well be that NVDA needs to be updated as it is being. That is
for others with
far more technical knowledge than I have to discuss. But the question
as to whether users should have the choice to use add-ons that may not
be compatible may be something that should be discussed. I don't like
programs that limit choice if the user may benefit by making choices
where the choice may or may not work or work properly. But what if it
does work properly or well enough to meet the users's needs?

Also, cavalierly saying things like there are thousands of other
synthesizers does not respect the user's desire or need, perhaps a
very good one, to use what he/she has been using.

I don't know if there is a player that is as easy or convenient to do
common tasks with such as jump to a time as Winamp, though I have only
tried VLC player and I use Windows Media Player for fast spoken word
listening. Also, VLC Player may have a clipping problem when
listening to content recorded at a high volume. But with or without
an add-on, I shall continue to use Winamp. I see no reason to learn
another program unless I need to.

Gene

On 12/8/18, Adriani Botez <adriani.botez@gmail.com> wrote:
Hello,

Actually people can stay to NVDA 2018.4 for some months until we manage to
contact all developers and discuss what they have to do. It is like at that
time when support for Windows XP has been dropped. Technology moves forward
and we must keep in touch with it if we want to become more advanced in what
we do. In this case, there are thousants of alternatives for speech
synthesizers. As Mick already pointed out, NV Access will certainly push
hard so that suppliers of sythesizers will update their engines as fast as
possible. And as far as old add-ons are concerned (i.e. extended winamp
etc.) it is very simple: if developers of those add-ons do not care about
them then users should look for other pieces of software which is more
modern and commonly used. For example VLC player or other music organizers.
Winamp is not the only player in the world. And if the developer did not
develop his or der add-on further then it is somehow clear that the
developer himself gave up using Winamp or so. This transition period will be
maybe half a year long or maybe one year. And I am prety sure that until
then every add-on will be compatible with NVDA. Even the Winamp add-on.

In my opinion, add-ons must work in line with NVDA. Not NVDA in line with
the add-ons. This is also valid in case of Jaws or other screen readers.
Because we have here the following hierarchy from top to bottom:
Accessibility API / scree reader / add-ons. And since the accessibility APIs
are updated regularly, screen readers must be updated as well. In turn,
add-ons must be updated either.

Best
Adriani





-----Ursprüngliche Nachricht-----
Von: nvda@nvda.groups.io <nvda@nvda.groups.io> Im Auftrag von Mobeen Iqbal
Gesendet: Samstag, 8. Dezember 2018 12:25
An: nvda@nvda.groups.io
Betreff: Re: [nvda] Important notice: a note or two about future
compatibility of add-ons on community add-ons website and elsewhere

I would be inclined to agree. The add-ons shouldn't be prevented from
running and the user should be given the option to suppress notifications
about compatibility until they upgrade to the next major release, then be
given the option to dismiss the notice again until the next upgrade and so
on. Yes there is a risk that the existing add-ons could stop working and
that they should be updated, but an example is the dolphin sam add-on which
some users use because they can understand dolphin's voices better. They
have hearing difficulties. I am going to see if the developer can be located
and the add-on updated, but users won't be happy if the add-ons are
prevented from running and their equipment stops working. I know that
prevention isn't on the cards so much but developers need to be careful so
people don't stop using NVDA.


Mo.



On 08/12/2018 11:12, Brian's Mail list account via Groups.Io wrote:
Right then. At the moment it is the majority of add ons that are
incompatible. I am thinking this is going to be a show stopper for
many as included in this list are toolbar Explorer, Application
dictionary, Extended winamp say prompts for copy etc, The 3D sounds
add on, Pico synth, Speech player in Espeak, open link with an add
on that is really very useful.
MP3 Direct cut and sundry others I use all the time.
I may in the end have to stop using alphas and intended the later
versions of NVDA unless all this work done by people can be either
fixed or nvda rethinks its Python 3 migration.
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
----- Original Message ----- From: "Joseph Lee"
<joseph.lee22590@gmail.com>
To: "'NVDA screen reader development'"
<nvda-devel@lists.sourceforge.net>
Sent: Saturday, December 08, 2018 5:30 AM
Subject: [nvda] Important notice: a note or two about future
compatibility of add-ons on community add-ons website and elsewhere


Dear NVDA community,



This is Joseph Lee, one of the code contributors to NVDA screen
reader project and a reviewer of community add-ons. I would like to
take this time to update you on what's been happening in regards to
future compatibility of add-ons hosted on various websites, as well
as rationale for compatibility notices you're seeing from recent NVDA
development releases (chiefly on alpha channel).



As of December 6, 2018, NVDA 2019.1 alpha snapshots (build 16382
onwards)
will prompt you to check compatibility of various add-ons when you're
installing snapshots. This is because NVDA will now check if any of
your add-ons are compatible with it by looking at two new manifest keys.
These
add-on manifest keys will tell NVDA if a given add-on is compatible
with latest NVDA release, as well as providing a minimum compatible
NVDA version if specified. After installing that alpha build and
beyond, if NVDA detects one or more add-ons are not compatible, it
will present a dialog at start up asking you to check which add-ons
you still wish to use despite them being flagged as incompatible.
This will be noticeable if you are using a third-party speech
synthesizer or braille display by default and somehow these are not
loading. Also, when trying to install new add-ons, if NVDA sees the
add-on is incompatible, it'll prompt a warning about it.



Prior to this change, you can install add-ons on any NVDA release
(including upcoming 2018.4), and it was up to add-ons to use features
provided by a given NVDA release. This meant really old add-ons could
be installed, and if not optimized for recent NVDA releases, the
add-on would not work as intended, and in some cases, fail to run
outright. Some add-ons do have specific NVDA version requirements,
but not all add-ons take advantage of this recommendation.



There are several reasons for the change as described above:



1. Python 3 transition: as some of you (I think, at this point, more
people) may know, NV Access and several developers (including I) are
researching possible roadblocks to Python 3 transition, and I'm
maintaining an actual Python 3 version of NVDA for testing purposes.
Given massive differences between Python 2 and 3, it was felt to
place add-on compatibility checks in place so you won't install
add-ons written in Python
2 on a Python 3 version of NVDA. This is one of the reasons for
adding minimum NVDA version checks for add-ons if appropriate. As of
today (December 8, 2018), at least three add-ons are Python 3 ready
(thus will require newer NVDA versions in the future), and I expect
that number to grow significantly in the next few months; the three
compatible add-ons are Resource Monitor, SystrayList, and Windows 10
App Essentials, with StationPlaylist Studio to be added to this list
in January 2019.
2. Various internal work planned for the future: these include
projects such as speech refactor (changing internals behind NVDA's
speech
functionality) and such that will cause some add-ons to fail to work
as advertised.



The new compatibility flags are:



* minimumNVDAVersion: specifies minimum version of NVDA the add-on is
compatible with.
* lastTestedNVDAVersion: latest compatible NVDA version for the
add-on.



These manifest keys are optional for now; in 2019, they will become
mandatory for ALL add-ons. I would go so far as say that they are
MANDATORY from now on, especially if you need to test your add-ons in
alpha snapshots and intend to produce a Python 3 version of your
add-ons.



As of December 8, 2018, only several add-ons hosted on community
add-ons website (addons.nvda-project.org) are truly future-proof
(compatibility flags are present). The good news is that add-on
authors do understand the impact this change will have on their
add-ons and some have begun updating their add-ons to add
compatibility flags; others plan to add changes once
2019.1 enters beta testing phase (based on past conversations), while
the community lost contact with authors of some add-ons (some of
which are
popular) and their add-ons will be flagged as incompatible unless
updates are released.



The following add-ons are NVDA 2019.1 compatible and thus won't cause
NVDA to flag them as incompatible:



* Add-on Updater
* Easy Table Navigator
* Enhanced Touch Gestures
* Focus Highlight
* Golden Cursor
* GoldWave
* ObjPad
* Object Location Tones
* Resource Monitor
* StationPlaylist Studio
* SystrayList
* Unicode Braille Input
* Virtual Review
* Windows 10 App Essentials
* And possibly more.



For add-ons not listed:



* For users: please contact authors of add-ons you're using and ask
for their thoughts and plans for add-on compatibility flags and other
future
work (see below for words about my add-ons).
* For developers: please think about the impact of this change and
update your add-ons. I don't expect all add-ons to be made compatible
by the
time 2019.1 stable version (or release candidate) is released, but at
least
for popular ones, please have your add-ons made compatible by the time
2019.1 beta 1 shows up. Also, I advise setting last tested version to
2019.2
so you can have plenty of time modernizing add-ons.



Notes for users of my add-ons or add-ons that'll be reviewed by me:



* For users: I expect all my add-ons (at least ones currently under
active support) to be made Python 3 ready no later than March 2019.
As far
as last tested version flag is concerned, I'll try my best to target
later
NVDA releases (for example, if using an add-on in NVDA 2019.1, the
compatibility flag will indicate support for at least NvDA 2019.3) so
you
won't have to worry about compatibility flag problems for a long time;
compatibility flags (at least last tested version flag) will be
updated once
or twice a year.
* For add-ons to be reviewed: I will look for compatibility flags (as
part of user experience portion of basic review) starting from February
2019; other add-on reviewers may or may not look for these flags.
* For Add-on Updater users: I will start enforcing add-on
compatibility flags from version 19.03; that is, Add-on Updater will
refuse
to install add-on updates if they do not specify at least last tested
version flag to align with NVDA 2019.1 behavior.



Thank you.

Cheers,

Joseph














 

Gene,

           It's a two way street, and software, any software, has never been about pleasing any single end user, but the target demographic.  Also, far too many confuse need and desire.  If there is a legitimate need then there is a mechanism for reporting same to the developers.  One can even use that mechanism to make feature requests.

           In the final analysis, it is the software developers who are subject to the outcry from users in all cases.  When it comes to a choice between being certain that the software will function as designed when used with add-ons, that takes precedence.  Add-ons can actually break core functionality, and when they do it's very seldom the add-on developer who hears about it (and there's been quite a bit of direct evidence for that recently in regard to NVDA Remote Support in the months just passed).  Many add-ons are abandoned entirely by their original developers (a good non-NVDA example of that was Webvisum).
 
           It is not cavalier, in any way, to say that user preference is secondary, by far, to keeping a functioning product.  It is no different than the assertion, that you yourself have made, that it is not up to employers to supply the screen reader of choice in their businesses, but to supply a screen reader.

           Users, blind, sighted, whatever have to adjust as software moves along.  'Twas ever thus.

           There should certainly be a period where "questionably compatible" add-ons be allowed to run if the user permits it, and it sounds like that is going to be supplied.  But, eventually, it can and must end or the risk to core functionality and the end user's ability to use same is just too great.

            When you add in the fact that NVDA updates to the software itself are not forced on the user, they do have the option to remain on an earlier version or to keep a "portable NVDA" archive so that if in a real pinch an ancient and not-currently-maintained add-on could be run.  Heaven knows I see people all the time nursing along outdated software.

--

Brian - Windows 10 Home, 64-Bit, Version 1809, Build 17763  

A great deal of intelligence can be invested in ignorance when the need for illusion is deep.

          ~ Saul Bellow, To Jerusalem and Back

 

 


Gene
 

I'm not sure just what is planned.  Perhaps it will give a choice unless an add-on is so old that it has no possibility of running and may be disruptive.  I may have misunderstood the message.  I thought that beyond a certain point, the user wouldn't be given a choice.
 
As far as being cavalier is concerned, I wasn't addressing that question.  I was saying the the person I responded to took what I consider to be a cavalier approach to the question by saying that there are thousands of synthesizers and that you can use a different player. 
 
I agree that a lot of people can use older versions of NVDA for a good while, perhaps years, and not suffer a loss in doing the tasks they want to do.  I was worried that the user wouldn't be given a choice to try using an old add-on if they needed to use a new version of NVDA.  That may not be true except when an add-on is so old that it won't run or will cause problems. 
 
Gene

----- Original Message -----
Sent: Saturday, December 08, 2018 8:30 AM
Subject: Re: [nvda] Important notice: a note or two about future compatibility of add-ons on community add-ons website and elsewhere

Gene,

           It's a two way street, and software, any software, has never been about pleasing any single end user, but the target demographic.  Also, far too many confuse need and desire.  If there is a legitimate need then there is a mechanism for reporting same to the developers.  One can even use that mechanism to make feature requests.

           In the final analysis, it is the software developers who are subject to the outcry from users in all cases.  When it comes to a choice between being certain that the software will function as designed when used with add-ons, that takes precedence.  Add-ons can actually break core functionality, and when they do it's very seldom the add-on developer who hears about it (and there's been quite a bit of direct evidence for that recently in regard to NVDA Remote Support in the months just passed).  Many add-ons are abandoned entirely by their original developers (a good non-NVDA example of that was Webvisum).
 
           It is not cavalier, in any way, to say that user preference is secondary, by far, to keeping a functioning product.  It is no different than the assertion, that you yourself have made, that it is not up to employers to supply the screen reader of choice in their businesses, but to supply a screen reader.

           Users, blind, sighted, whatever have to adjust as software moves along.  'Twas ever thus.

           There should certainly be a period where "questionably compatible" add-ons be allowed to run if the user permits it, and it sounds like that is going to be supplied.  But, eventually, it can and must end or the risk to core functionality and the end user's ability to use same is just too great.

            When you add in the fact that NVDA updates to the software itself are not forced on the user, they do have the option to remain on an earlier version or to keep a "portable NVDA" archive so that if in a real pinch an ancient and not-currently-maintained add-on could be run.  Heaven knows I see people all the time nursing along outdated software.

--

Brian - Windows 10 Home, 64-Bit, Version 1809, Build 17763  

A great deal of intelligence can be invested in ignorance when the need for illusion is deep.

          ~ Saul Bellow, To Jerusalem and Back

 

 


 

Hi,

Braille Extender has been updated recently to include compatibility flags.

Cheers,

Joseph

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Devin Prater
Sent: Friday, December 7, 2018 10:46 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Important notice: a note or two about future compatibility of add-ons on community add-ons website and elsewhere

 

Thanks so much for all this information. I hope that the author of Braille Extender updates that add-on, as it is one of the most useful admins to me.



On Dec 7, 2018, at 11:50 PM, Joseph Lee <joseph.lee22590@...> wrote:

 

Hi,

Yes, I and another NVDA developer wrote messages concerning this to add-on authors.

By the way, one more thing: I’ll release patches for most of the add-ons I’m maintaining (resource Monitor and StationPlaylist, for instance) around Christmas to extend last tested NVDA version flag to 2019.3. The only exception will be Unicode Braille Input, which is no longer maintained by me.

Cheers,

Joseph

 

From: nvda@nvda.groups.io<nvda@nvda.groups.io> On Behalf Of David Goldfield
Sent: Friday, December 7, 2018 9:44 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Important notice: a note or two about future compatibility of add-ons on community add-ons website and elsewhere

 

Joseph,

Thank you for alerting us to this situation. I am somewhat concerned as I do use some third-party add-ons not hosted on the community add-ons page but which are well-known and legal. I'm wondering if the developers of these add-ons have been informed about this change? Specifically, I use the Code Factory Eloquence and Vocalizer add-on, Acapela voices, Dictation Bridge and NVDA Remote. I also hope that Clipspeak and Clip Contents Designer will be updated but I realize these are not your apps.

Thank you again.

 

David Goldfield, Assistive Technology Specialist WWW.David-Goldfield.Com

On 12/8/2018 12:30 AM, Joseph Lee wrote:

Dear NVDA community,

 

This is Joseph Lee, one of the code contributors to NVDA screen reader project and a reviewer of community add-ons. I would like to take this time to update you on what’s been happening in regards to future compatibility of add-ons hosted on various websites, as well as rationale for compatibility notices you’re seeing from recent NVDA development releases (chiefly on alpha channel).

 

As of December 6, 2018, NVDA 2019.1 alpha snapshots (build 16382 onwards) will prompt you to check compatibility of various add-ons when you’re installing snapshots. This is because NVDA will now check if any of your add-ons are compatible with it by looking at two new manifest keys. These add-on manifest keys will tell NVDA if a given add-on is compatible with latest NVDA release, as well as providing a minimum compatible NVDA version if specified. After installing that alpha build and beyond, if NVDA detects one or more add-ons are not compatible, it will present a dialog at start up asking you to check which add-ons you still wish to use despite them being flagged as incompatible. This will be noticeable if you are using a third-party speech synthesizer or braille display by default and somehow these are not loading. Also, when trying to install new add-ons, if NVDA sees the add-on is incompatible, it’ll prompt a warning about it.

 

Prior to this change, you can install add-ons on any NVDA release (including upcoming 2018.4), and it was up to add-ons to use features provided by a given NVDA release. This meant really old add-ons could be installed, and if not optimized for recent NVDA releases, the add-on would not work as intended, and in some cases, fail to run outright. Some add-ons do have specific NVDA version requirements, but not all add-ons take advantage of this recommendation.

 

There are several reasons for the change as described above:

 

  1. Python 3 transition: as some of you (I think, at this point, more people) may know, NV Access and several developers (including I) are researching possible roadblocks to Python 3 transition, and I’m maintaining an actual Python 3 version of NVDA for testing purposes. Given massive differences between Python 2 and 3, it was felt to place add-on compatibility checks in place so you won’t install add-ons written in Python 2 on a Python 3 version of NVDA. This is one of the reasons for adding minimum NVDA version checks for add-ons if appropriate. As of today (December 8, 2018), at least three add-ons are Python 3 ready (thus will require newer NVDA versions in the future), and I expect that number to grow significantly in the next few months; the three compatible add-ons are Resource Monitor, SystrayList, and Windows 10 App Essentials, with StationPlaylist Studio to be added to this list in January 2019. 
  2. Various internal work planned for the future: these include projects such as speech refactor (changing internals behind NVDA’s speech functionality) and such that will cause some add-ons to fail to work as advertised. 

 

The new compatibility flags are:

 

  • minimumNVDAVersion: specifies minimum version of NVDA the add-on is compatible with. 
  • lastTestedNVDAVersion: latest compatible NVDA version for the add-on. 

 

These manifest keys are optional for now; in 2019, they will become mandatory for ALL add-ons. I would go so far as say that they are MANDATORY from now on, especially if you need to test your add-ons in alpha snapshots and intend to produce a Python 3 version of your add-ons.

 

As of December 8, 2018, only several add-ons hosted on community add-ons website (addons.nvda-project.org) are truly future-proof (compatibility flags are present). The good news is that add-on authors do understand the impact this change will have on their add-ons and some have begun updating their add-ons to add compatibility flags; others plan to add changes once 2019.1 enters beta testing phase (based on past conversations), while the community lost contact with authors of some add-ons (some of which are popular) and their add-ons will be flagged as incompatible unless updates are released.

 

The following add-ons are NVDA 2019.1 compatible and thus won’t cause NVDA to flag them as incompatible:

 

  • Add-on Updater 
  • Easy Table Navigator 
  • Enhanced Touch Gestures 
  • Focus Highlight 
  • Golden Cursor 
  • GoldWave 
  • ObjPad 
  • Object Location Tones 
  • Resource Monitor 
  • StationPlaylist Studio 
  • SystrayList 
  • Unicode Braille Input 
  • Virtual Review 
  • Windows 10 App Essentials 
  • And possibly more. 

 

For add-ons not listed:

 

  • For users: please contact authors of add-ons you’re using and ask for their thoughts and plans for add-on compatibility flags and other future work (see below for words about my add-ons). 
  • For developers: please think about the impact of this change and update your add-ons. I don’t expect all add-ons to be made compatible by the time 2019.1 stable version (or release candidate) is released, but at least for popular ones, please have your add-ons made compatible by the time 2019.1 beta 1 shows up. Also, I advise setting last tested version to 2019.2 so you can have plenty of time modernizing add-ons. 

 

Notes for users of my add-ons or add-ons that’ll be reviewed by me:

 

  • For users: I expect all my add-ons (at least ones currently under active support) to be made Python 3 ready no later than March 2019. As far as last tested version flag is concerned, I’ll try my best to target later NVDA releases (for example, if using an add-on in NVDA 2019.1, the compatibility flag will indicate support for at least NvDA 2019.3) so you won’t have to worry about compatibility flag problems for a long time; compatibility flags (at least last tested version flag) will be updated once or twice a year. 
  • For add-ons to be reviewed: I will look for compatibility flags (as part of user experience portion of basic review) starting from February 2019; other add-on reviewers may or may not look for these flags. 
  • For Add-on Updater users: I will start enforcing add-on compatibility flags from version 19.03; that is, Add-on Updater will refuse to install add-on updates if they do not specify at least last tested version flag to align with NVDA 2019.1 behavior. 

 

Thank you.

Cheers,

Joseph

 


Tony Malykh
 

Joseph,
Are you saying that we are supposed to state
lastTestedNVDAVersion=2019.2 even though 2019.1 has not been released
yet? That sounds really weird to me. In this case the name of this
flag is very misleading. Also as an add-on author, there is some
motivation to set this value to some distant date in the future, like
2033.1. I'm not saying I'm going to do that, but someone else might.
I understand, you cannot expect all the add-on authors to test all
their add-ons every single release. That's why you recommend setting
lastTestedNVDAVersion to be some date in the future. But there is just
something wrong with this approach.

It's probably too late at this point to express my opinion, since
thiese flags have already been agreed upon and implemented, but maybe
better late than never. Here are my thoughts.
1. The reason for these compatibility flags is that there are a number
of major changes coming up in NVDA, such as Python 3, speech
refactoring, etc, that can break compatibility with many add-ons. We'd
like to push add-on authors to catch up with these changes.
2. Correct me if I'm wrong, but it has not been always like this.
There were many years with no major API-breaking changes to NVDA. And
in the future, after migrating to Python 3 we can reasonably expect
less addon-breaking changes.
3. With these flags, you are requiring add-on authors to at least
update these flags on a quarterly basis. I expect many add-ons won't
be updated by their authors. In this case:
3.1. You are Pushing users to agree to multiple warnings about add-on
incompatibility. There are many problems with this. First, besides
Python3 and speech refactoring, most of these warnings will be wrong,
in the sense that add-ons keep working, despite being not tested. In
this case users will quickly learn to skip through all the warnings
wihtout paying attention to them. It might only be an annoyance to the
users. As a side effect, the number of users who use any add-ons will
go down, since using any add-ons will be associated with clicking
through dozens of useless warnings.
3.2. As an add-on author, you create a motivation for me to lie and
specify some date in the future, like 2033, to be the latest tested
version. Especially, you explicitly asked the authors to do so,
albeit, not that far into the future. At least my users won't suffer
from extra warnings. And I'll fix my addo-ns whenever there is a
problem.
3.3. Life is busy. I might be too lazy to update lastTestedNVDAVersion
flag on a quarterly basis just for the purpose of updating it.

4. Here is what I propose as an alternative.
4.1. Identify specific changes that are likely to break addon
compatibility. Such as Python3 migration and speech refactoring.
4.2. Create a separate flag for each of these changes. E.g.
PYTHON3_COMPATIBLE=True. If the flag is not present, it is reasonable
to assume, that this add-on is not compatible. In this case a warning
message does make a lot of sense, since it is likely that this add-on
would be broken if not explicitly made Python3 compatible.
4.3. In this case all the warnings are reasonable. You wouldn't be
pushing users to ignore warnings. You wouldn't be pushing add-on
authors to either lie about last tested date, or update the flag on a
quarterly basis.

Joseph, I know you've put a lot of effort into this and you've done a
lot of good things to this community. But I just want to express my
opinion. In the end as an add-on author I will still play by the
rules. But I just wanted to point out some problems that might arise
from these new flags in the near future.

Best regards
Tony

On 12/8/18, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi,

Braille Extender has been updated recently to include compatibility flags.

Cheers,

Joseph



From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Devin Prater
Sent: Friday, December 7, 2018 10:46 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Important notice: a note or two about future
compatibility of add-ons on community add-ons website and elsewhere



Thanks so much for all this information. I hope that the author of Braille
Extender updates that add-on, as it is one of the most useful admins to me.





On Dec 7, 2018, at 11:50 PM, Joseph Lee <joseph.lee22590@gmail.com
<mailto:joseph.lee22590@gmail.com> > wrote:



Hi,

Yes, I and another NVDA developer wrote messages concerning this to add-on
authors.

By the way, one more thing: I’ll release patches for most of the add-ons I’m
maintaining (resource Monitor and StationPlaylist, for instance) around
Christmas to extend last tested NVDA version flag to 2019.3. The only
exception will be Unicode Braille Input, which is no longer maintained by
me.

Cheers,

Joseph



From: <mailto:nvda@nvda.groups.io> nvda@nvda.groups.io<
<mailto:nvda@nvda.groups.io> nvda@nvda.groups.io> On Behalf Of David
Goldfield
Sent: Friday, December 7, 2018 9:44 PM
To: <mailto:nvda@nvda.groups.io> nvda@nvda.groups.io
Subject: Re: [nvda] Important notice: a note or two about future
compatibility of add-ons on community add-ons website and elsewhere



Joseph,

Thank you for alerting us to this situation. I am somewhat concerned as I do
use some third-party add-ons not hosted on the community add-ons page but
which are well-known and legal. I'm wondering if the developers of these
add-ons have been informed about this change? Specifically, I use the Code
Factory Eloquence and Vocalizer add-on, Acapela voices, Dictation Bridge and
NVDA Remote. I also hope that Clipspeak and Clip Contents Designer will be
updated but I realize these are not your apps.

Thank you again.



David Goldfield, Assistive Technology Specialist
<http://www.david-goldfield.com/> WWW.David-Goldfield.Com

On 12/8/2018 12:30 AM, Joseph Lee wrote:

Dear NVDA community,



This is Joseph Lee, one of the code contributors to NVDA screen reader
project and a reviewer of community add-ons. I would like to take this time
to update you on what’s been happening in regards to future compatibility of
add-ons hosted on various websites, as well as rationale for compatibility
notices you’re seeing from recent NVDA development releases (chiefly on
alpha channel).



As of December 6, 2018, NVDA 2019.1 alpha snapshots (build 16382 onwards)
will prompt you to check compatibility of various add-ons when you’re
installing snapshots. This is because NVDA will now check if any of your
add-ons are compatible with it by looking at two new manifest keys. These
add-on manifest keys will tell NVDA if a given add-on is compatible with
latest NVDA release, as well as providing a minimum compatible NVDA version
if specified. After installing that alpha build and beyond, if NVDA detects
one or more add-ons are not compatible, it will present a dialog at start up
asking you to check which add-ons you still wish to use despite them being
flagged as incompatible. This will be noticeable if you are using a
third-party speech synthesizer or braille display by default and somehow
these are not loading. Also, when trying to install new add-ons, if NVDA
sees the add-on is incompatible, it’ll prompt a warning about it.



Prior to this change, you can install add-ons on any NVDA release (including
upcoming 2018.4), and it was up to add-ons to use features provided by a
given NVDA release. This meant really old add-ons could be installed, and if
not optimized for recent NVDA releases, the add-on would not work as
intended, and in some cases, fail to run outright. Some add-ons do have
specific NVDA version requirements, but not all add-ons take advantage of
this recommendation.



There are several reasons for the change as described above:



1. Python 3 transition: as some of you (I think, at this point, more people)
may know, NV Access and several developers (including I) are researching
possible roadblocks to Python 3 transition, and I’m maintaining an actual
Python 3 version of NVDA for testing purposes. Given massive differences
between Python 2 and 3, it was felt to place add-on compatibility checks in
place so you won’t install add-ons written in Python 2 on a Python 3 version
of NVDA. This is one of the reasons for adding minimum NVDA version checks
for add-ons if appropriate. As of today (December 8, 2018), at least three
add-ons are Python 3 ready (thus will require newer NVDA versions in the
future), and I expect that number to grow significantly in the next few
months; the three compatible add-ons are Resource Monitor, SystrayList, and
Windows 10 App Essentials, with StationPlaylist Studio to be added to this
list in January 2019.
2. Various internal work planned for the future: these include projects such
as speech refactor (changing internals behind NVDA’s speech functionality)
and such that will cause some add-ons to fail to work as advertised.



The new compatibility flags are:



* minimumNVDAVersion: specifies minimum version of NVDA the add-on is
compatible with.
* lastTestedNVDAVersion: latest compatible NVDA version for the add-on.



These manifest keys are optional for now; in 2019, they will become
mandatory for ALL add-ons. I would go so far as say that they are MANDATORY
from now on, especially if you need to test your add-ons in alpha snapshots
and intend to produce a Python 3 version of your add-ons.



As of December 8, 2018, only several add-ons hosted on community add-ons
website ( <http://addons.nvda-project.org/> addons.nvda-project.org) are
truly future-proof (compatibility flags are present). The good news is that
add-on authors do understand the impact this change will have on their
add-ons and some have begun updating their add-ons to add compatibility
flags; others plan to add changes once 2019.1 enters beta testing phase
(based on past conversations), while the community lost contact with authors
of some add-ons (some of which are popular) and their add-ons will be
flagged as incompatible unless updates are released.



The following add-ons are NVDA 2019.1 compatible and thus won’t cause NVDA
to flag them as incompatible:



* Add-on Updater
* Easy Table Navigator
* Enhanced Touch Gestures
* Focus Highlight
* Golden Cursor
* GoldWave
* ObjPad
* Object Location Tones
* Resource Monitor
* StationPlaylist Studio
* SystrayList
* Unicode Braille Input
* Virtual Review
* Windows 10 App Essentials
* And possibly more.



For add-ons not listed:



* For users: please contact authors of add-ons you’re using and ask for
their thoughts and plans for add-on compatibility flags and other future
work (see below for words about my add-ons).
* For developers: please think about the impact of this change and update
your add-ons. I don’t expect all add-ons to be made compatible by the time
2019.1 stable version (or release candidate) is released, but at least for
popular ones, please have your add-ons made compatible by the time 2019.1
beta 1 shows up. Also, I advise setting last tested version to 2019.2 so you
can have plenty of time modernizing add-ons.



Notes for users of my add-ons or add-ons that’ll be reviewed by me:



* For users: I expect all my add-ons (at least ones currently under active
support) to be made Python 3 ready no later than March 2019. As far as last
tested version flag is concerned, I’ll try my best to target later NVDA
releases (for example, if using an add-on in NVDA 2019.1, the compatibility
flag will indicate support for at least NvDA 2019.3) so you won’t have to
worry about compatibility flag problems for a long time; compatibility flags
(at least last tested version flag) will be updated once or twice a year.
* For add-ons to be reviewed: I will look for compatibility flags (as part
of user experience portion of basic review) starting from February 2019;
other add-on reviewers may or may not look for these flags.
* For Add-on Updater users: I will start enforcing add-on compatibility
flags from version 19.03; that is, Add-on Updater will refuse to install
add-on updates if they do not specify at least last tested version flag to
align with NVDA 2019.1 behavior.



Thank you.

Cheers,

Joseph