Date   
Re: Add-on template and update channel definition: updates, a word about update channel definition

Andy B.
 

Hi,

 

This makes sense. However, it brings up another interesting problem. How will add-on authors reliably get their add-on releases to the add-on files repo? Currently, it takes someone with read/write access to add the files. Now you have a coordination/timing problem because translators/maintainers keep the website entries up to date while someone else updates the add-on file. In some cases, a request to have an add-on file updated may get lost in the list email. Is there an easier/faster way to get add-on files into the repo?

 

 

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph Lee
Sent: Saturday, August 10, 2019 11:38 PM
To: nvda-devel@groups.io
Subject: [nvda-devel] Add-on template and update channel definition: updates, a word about update channel definition

 

Hi all,

 

Prompted by a discussion on nvda-devel list between Luke Davis and I regarding clarity of update channel definition, coupled with a report from Brian Gaff about some add-ons shipping with update channel set to “stable” for stable releases, I decided to take a look at add-on template repo and make the following change:

 

Update channel definition for build vars dictionary: it’ll say:

 

Add-on update channel (default is None, denoting stable releases, and for development releases, use "dev"; do not change unless you know what you are doing)

 

This should clarify the overall purpose of that manifest key, meaning of “None”, and remind you not to change it unless you are releasing something other than stable releases (i.e. know what you are doing). For the purposes of the template and add-on update checks (currently performed by Add-on Updater, and one day, by NVDA itself unless the scheme changes), setting update channel to None means this is a stable release. Many of you should leave it at default value of None unless you wish to publish development snapshots or need to maintain channels in addition to stable (and/or dev).

 

You might be asking, why None for stable channel? For some of you, this is a repeat, so please bear with me:

 

In 2012, NV Access, together with some contributors, formally defined and implemented NVDA add-on management facility. Prior to NvDA 2012.2, people wishing to extend NVDA would write Python modules and would place them in now deprecated plugin directories (appModules, globalPlugins, brailleDisplayDrivers, synthDrivers inside NVDA user directory). The add-ons subsystem was an attempt to let plugin writers, now commonly known as add-on authors, to package modules inside a compressed (zip) file with an .nvda-addon extension, and once opened by NVDA, add-on packages will be extracted to the newly created “addons” folder inside dedicated subfolders (named according to the add-on name/ID defined in the manifest).

 

In an attempt to coordinate add-on development and collect add-ons from the community and showcase them under one roof, in 2013, the add-ons community mailing list (first generation on Freelists.org) was formed, along with the opening of the NVDA community add-ons website (addons.nvda-project.org). The backbone of the community add-ons website is hosted on an add-on files repository (Bitbucket) in the form of a PHP file that records add-ons hosted on the website and download links for them. When an add-on is approved for community add-ons website, a unique shorthand key was generated (or rather, created) for the add-on and added to the database. Back then, most add-ons were listed as stable versions (with some of them going through development builds), hence the key itself without qualifiers denote stable releases. Subsequently, once the add-on review process was formalized in 2015, more add-ons started using the “-dev” suffix to denote add-ons under development. This process continues today even with the add-ons mailing list moving to Groups.IO in recent years.

 

Then around this time last year (2018), I released Add-on Updater, powered by standalone update facility from StationPlaylist and Windows 10 App Essentials. Borrowing the conventions from many years, this add-on treats add-on keys without qualifiers as stable releases. The add-on contains a map of add-on ID’s to shorthand keys used to look up add-on download links/versions from the add-ons website.

 

The add-on would then calculate the “update channel” value as follows:

 

  1. If an add-on does not define an update channel in the manifest (old add-ons), it is treated as a stable channel. This check is becoming rare.
  2. If the update channel is defined as “None” (technically, it should be None, but ConfigObj turns this into a string), it is a stable channel.
  3. If a different update channel is defined, a qualifier is recorded. Technically, stable channel does have a qualifier, but it is nothing.
  4. Depending on channel obtained, the update channel value (to be passed to a function/thread responsible for connecting to the website and retrieving add-on update information) is either the shorthand key (stable release) or shorthand key + “-“ (hyphen) followed by the name of the custom channel. This is a necessary work because that is how add-on download links are recorded on the website.

 

For example, for Enhanced Touch Gestures, if you are checking for stable releases, the shorthand key (“ets”) alone will be the update channel value; if you are looking for development releases, the value becomes “ets-dev”. Or perhaps I release a custom build of Enhanced Touch Gestures, say “alpha”. The value then becomes “ets-alpha”.

 

So far, it is going well. However, it falls apart when trying to retrieve update information for some add-ons: due to ambiguity present in current add-on template (my sincerest apologies), some authors defined “stable” for stable releases when it should not be defined as such. For example, Toolbars Explorer defines “stable” for stable releases, which means instead of looking at “tbx”, it will actually look up “tbx-stable” which actually doesn’t exist. This is the reason why some of you could not obtain latest stable releases for add-ons like Toolbars Explorer, hence the correction and advice noted above.

 

I will push necessary changes to add-on template tonight.

 

Because it takes time to update all affected add-ons to change their stable channel definitions (coupled with Python 3 porting work), I will not enforce stable release definition change today: I will give you 30 days (until September 10, 2019) to update add-ons. September 10th will also be the day I will release Add-on Updater 19.09 (the second mandatory update for everyone), which will enforce this change; the next version of this add-on, version 19.08.1 scheduled shortly after NVDA 2019.2 stable version is released, will include a compatibility workaround for add-ons affected by stable channel definition problem (note that 19.08.1 will require NVDA 2019.2 due to maintenance policy for Add-on Updater).

 

A huge caveat: the update channel scheme may change once NVDA starts checking for add-on updates on its own (the missing puzzle pieces are server-side work and data exchange mechanisms; others such as update check client and the user interface are done).

 

Thanks, and again, my sincerest apologies for causing ambiguities in the first place and for causing an inconvenience.

Cheers,

Joseph

Re: Add-on template and update channel definition: updates, a word about update channel definition

Brian's Mail list account
 

Hi, yes this explains why I can get toolbars Explorer going myself via a modified file but the official fixed version loads in some versions of nvda but not in others even though its flagged as downloadable.
It may also go some way to define my issues in retro creating an add on by just updating the source in the add on and the versions in the manifest. I had not appreciated the power of the channel defining item.

One other thing. Has the Alpha snap had its auto update disabled? I only seem to find updates manually, even though the checkbox is checked for auto updates. The beta and RC still work.
One other thing I have noticed that can cause problems is that if people are doing what I did and modifying the code for the add on source and the manifest in situe for alpha snaps, make sure any of the compiled files are removed before you restart nvda to test it. I have no idea why this makes a difference but it seems Python 3 makes a new sub directory for the compiled code and does not delete the old compiled Python 2 code.

Brian

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

----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Sunday, August 11, 2019 4:38 AM
Subject: [nvda-devel] Add-on template and update channel definition: updates, a word about update channel definition


Hi all,



Prompted by a discussion on nvda-devel list between Luke Davis and I
regarding clarity of update channel definition, coupled with a report from
Brian Gaff about some add-ons shipping with update channel set to "stable"
for stable releases, I decided to take a look at add-on template repo and
make the following change:



Update channel definition for build vars dictionary: it'll say:



Add-on update channel (default is None, denoting stable releases, and for
development releases, use "dev"; do not change unless you know what you are
doing)



This should clarify the overall purpose of that manifest key, meaning of
"None", and remind you not to change it unless you are releasing something
other than stable releases (i.e. know what you are doing). For the purposes
of the template and add-on update checks (currently performed by Add-on
Updater, and one day, by NVDA itself unless the scheme changes), setting
update channel to None means this is a stable release. Many of you should
leave it at default value of None unless you wish to publish development
snapshots or need to maintain channels in addition to stable (and/or dev).



You might be asking, why None for stable channel? For some of you, this is a
repeat, so please bear with me:



In 2012, NV Access, together with some contributors, formally defined and
implemented NVDA add-on management facility. Prior to NvDA 2012.2, people
wishing to extend NVDA would write Python modules and would place them in
now deprecated plugin directories (appModules, globalPlugins,
brailleDisplayDrivers, synthDrivers inside NVDA user directory). The add-ons
subsystem was an attempt to let plugin writers, now commonly known as add-on
authors, to package modules inside a compressed (zip) file with an
.nvda-addon extension, and once opened by NVDA, add-on packages will be
extracted to the newly created "addons" folder inside dedicated subfolders
(named according to the add-on name/ID defined in the manifest).



In an attempt to coordinate add-on development and collect add-ons from the
community and showcase them under one roof, in 2013, the add-ons community
mailing list (first generation on Freelists.org) was formed, along with the
opening of the NVDA community add-ons website (addons.nvda-project.org). The
backbone of the community add-ons website is hosted on an add-on files
repository (Bitbucket) in the form of a PHP file that records add-ons hosted
on the website and download links for them. When an add-on is approved for
community add-ons website, a unique shorthand key was generated (or rather,
created) for the add-on and added to the database. Back then, most add-ons
were listed as stable versions (with some of them going through development
builds), hence the key itself without qualifiers denote stable releases.
Subsequently, once the add-on review process was formalized in 2015, more
add-ons started using the "-dev" suffix to denote add-ons under development.
This process continues today even with the add-ons mailing list moving to
Groups.IO in recent years.



Then around this time last year (2018), I released Add-on Updater, powered
by standalone update facility from StationPlaylist and Windows 10 App
Essentials. Borrowing the conventions from many years, this add-on treats
add-on keys without qualifiers as stable releases. The add-on contains a map
of add-on ID's to shorthand keys used to look up add-on download
links/versions from the add-ons website.



The add-on would then calculate the "update channel" value as follows:



1. If an add-on does not define an update channel in the manifest (old
add-ons), it is treated as a stable channel. This check is becoming rare.
2. If the update channel is defined as "None" (technically, it should
be None, but ConfigObj turns this into a string), it is a stable channel.
3. If a different update channel is defined, a qualifier is recorded.
Technically, stable channel does have a qualifier, but it is nothing.
4. Depending on channel obtained, the update channel value (to be
passed to a function/thread responsible for connecting to the website and
retrieving add-on update information) is either the shorthand key (stable
release) or shorthand key + "-" (hyphen) followed by the name of the custom
channel. This is a necessary work because that is how add-on download links
are recorded on the website.



For example, for Enhanced Touch Gestures, if you are checking for stable
releases, the shorthand key ("ets") alone will be the update channel value;
if you are looking for development releases, the value becomes "ets-dev". Or
perhaps I release a custom build of Enhanced Touch Gestures, say "alpha".
The value then becomes "ets-alpha".



So far, it is going well. However, it falls apart when trying to retrieve
update information for some add-ons: due to ambiguity present in current
add-on template (my sincerest apologies), some authors defined "stable" for
stable releases when it should not be defined as such. For example, Toolbars
Explorer defines "stable" for stable releases, which means instead of
looking at "tbx", it will actually look up "tbx-stable" which actually
doesn't exist. This is the reason why some of you could not obtain latest
stable releases for add-ons like Toolbars Explorer, hence the correction and
advice noted above.



I will push necessary changes to add-on template tonight.



Because it takes time to update all affected add-ons to change their stable
channel definitions (coupled with Python 3 porting work), I will not enforce
stable release definition change today: I will give you 30 days (until
September 10, 2019) to update add-ons. September 10th will also be the day I
will release Add-on Updater 19.09 (the second mandatory update for
everyone), which will enforce this change; the next version of this add-on,
version 19.08.1 scheduled shortly after NVDA 2019.2 stable version is
released, will include a compatibility workaround for add-ons affected by
stable channel definition problem (note that 19.08.1 will require NVDA
2019.2 due to maintenance policy for Add-on Updater).



A huge caveat: the update channel scheme may change once NVDA starts
checking for add-on updates on its own (the missing puzzle pieces are
server-side work and data exchange mechanisms; others such as update check
client and the user interface are done).



Thanks, and again, my sincerest apologies for causing ambiguities in the
first place and for causing an inconvenience.

Cheers,

Joseph



Re: Add-on template and update channel definition: updates, a word about update channel definition

Brian's Mail list account
 

And some people may find like myself that although not a coder using the normal ways of working have made a perfectly valid fix to an add on which has not been converted yet and it only exists as the add on or even perhaps as the source file from inside the add on. I feel there should be somebody willing to test these as it could prove a shortcut to getting abandoned add ons to work.
I'm no complex programmer but one does learn something of the syntax over time and cannot put in the work to do more than modify existing code very slightly.
Brian

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

----- Original Message -----
From: "Andy B." <sonfire11@...>
To: <nvda-devel@groups.io>
Sent: Sunday, August 11, 2019 9:30 AM
Subject: Re: [nvda-devel] Add-on template and update channel definition: updates, a word about update channel definition


Hi,



This makes sense. However, it brings up another interesting problem. How
will add-on authors reliably get their add-on releases to the add-on files
repo? Currently, it takes someone with read/write access to add the files.
Now you have a coordination/timing problem because translators/maintainers
keep the website entries up to date while someone else updates the add-on
file. In some cases, a request to have an add-on file updated may get lost
in the list email. Is there an easier/faster way to get add-on files into
the repo?







From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph Lee
Sent: Saturday, August 10, 2019 11:38 PM
To: nvda-devel@groups.io
Subject: [nvda-devel] Add-on template and update channel definition:
updates, a word about update channel definition



Hi all,



Prompted by a discussion on nvda-devel list between Luke Davis and I
regarding clarity of update channel definition, coupled with a report from
Brian Gaff about some add-ons shipping with update channel set to "stable"
for stable releases, I decided to take a look at add-on template repo and
make the following change:



Update channel definition for build vars dictionary: it'll say:



Add-on update channel (default is None, denoting stable releases, and for
development releases, use "dev"; do not change unless you know what you are
doing)



This should clarify the overall purpose of that manifest key, meaning of
"None", and remind you not to change it unless you are releasing something
other than stable releases (i.e. know what you are doing). For the purposes
of the template and add-on update checks (currently performed by Add-on
Updater, and one day, by NVDA itself unless the scheme changes), setting
update channel to None means this is a stable release. Many of you should
leave it at default value of None unless you wish to publish development
snapshots or need to maintain channels in addition to stable (and/or dev).



You might be asking, why None for stable channel? For some of you, this is a
repeat, so please bear with me:



In 2012, NV Access, together with some contributors, formally defined and
implemented NVDA add-on management facility. Prior to NvDA 2012.2, people
wishing to extend NVDA would write Python modules and would place them in
now deprecated plugin directories (appModules, globalPlugins,
brailleDisplayDrivers, synthDrivers inside NVDA user directory). The add-ons
subsystem was an attempt to let plugin writers, now commonly known as add-on
authors, to package modules inside a compressed (zip) file with an
.nvda-addon extension, and once opened by NVDA, add-on packages will be
extracted to the newly created "addons" folder inside dedicated subfolders
(named according to the add-on name/ID defined in the manifest).



In an attempt to coordinate add-on development and collect add-ons from the
community and showcase them under one roof, in 2013, the add-ons community
mailing list (first generation on Freelists.org) was formed, along with the
opening of the NVDA community add-ons website (addons.nvda-project.org). The
backbone of the community add-ons website is hosted on an add-on files
repository (Bitbucket) in the form of a PHP file that records add-ons hosted
on the website and download links for them. When an add-on is approved for
community add-ons website, a unique shorthand key was generated (or rather,
created) for the add-on and added to the database. Back then, most add-ons
were listed as stable versions (with some of them going through development
builds), hence the key itself without qualifiers denote stable releases.
Subsequently, once the add-on review process was formalized in 2015, more
add-ons started using the "-dev" suffix to denote add-ons under development.
This process continues today even with the add-ons mailing list moving to
Groups.IO in recent years.



Then around this time last year (2018), I released Add-on Updater, powered
by standalone update facility from StationPlaylist and Windows 10 App
Essentials. Borrowing the conventions from many years, this add-on treats
add-on keys without qualifiers as stable releases. The add-on contains a map
of add-on ID's to shorthand keys used to look up add-on download
links/versions from the add-ons website.



The add-on would then calculate the "update channel" value as follows:



1. If an add-on does not define an update channel in the manifest (old
add-ons), it is treated as a stable channel. This check is becoming rare.
2. If the update channel is defined as "None" (technically, it should
be None, but ConfigObj turns this into a string), it is a stable channel.
3. If a different update channel is defined, a qualifier is recorded.
Technically, stable channel does have a qualifier, but it is nothing.
4. Depending on channel obtained, the update channel value (to be
passed to a function/thread responsible for connecting to the website and
retrieving add-on update information) is either the shorthand key (stable
release) or shorthand key + "-" (hyphen) followed by the name of the custom
channel. This is a necessary work because that is how add-on download links
are recorded on the website.



For example, for Enhanced Touch Gestures, if you are checking for stable
releases, the shorthand key ("ets") alone will be the update channel value;
if you are looking for development releases, the value becomes "ets-dev". Or
perhaps I release a custom build of Enhanced Touch Gestures, say "alpha".
The value then becomes "ets-alpha".



So far, it is going well. However, it falls apart when trying to retrieve
update information for some add-ons: due to ambiguity present in current
add-on template (my sincerest apologies), some authors defined "stable" for
stable releases when it should not be defined as such. For example, Toolbars
Explorer defines "stable" for stable releases, which means instead of
looking at "tbx", it will actually look up "tbx-stable" which actually
doesn't exist. This is the reason why some of you could not obtain latest
stable releases for add-ons like Toolbars Explorer, hence the correction and
advice noted above.



I will push necessary changes to add-on template tonight.



Because it takes time to update all affected add-ons to change their stable
channel definitions (coupled with Python 3 porting work), I will not enforce
stable release definition change today: I will give you 30 days (until
September 10, 2019) to update add-ons. September 10th will also be the day I
will release Add-on Updater 19.09 (the second mandatory update for
everyone), which will enforce this change; the next version of this add-on,
version 19.08.1 scheduled shortly after NVDA 2019.2 stable version is
released, will include a compatibility workaround for add-ons affected by
stable channel definition problem (note that 19.08.1 will require NVDA
2019.2 due to maintenance policy for Add-on Updater).



A huge caveat: the update channel scheme may change once NVDA starts
checking for add-on updates on its own (the missing puzzle pieces are
server-side work and data exchange mechanisms; others such as update check
client and the user interface are done).



Thanks, and again, my sincerest apologies for causing ambiguities in the
first place and for causing an inconvenience.

Cheers,

Joseph





Re: Add-on template and update channel definition: updates, a word about update channel definition

 

Hi,

Usually that request should be sent to add-ons list, and either I or someone will update the add-on files repo (I usually take care of that within a day of that request arriving in my inbox, at least if I’m able).

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Andy B.
Sent: Sunday, August 11, 2019 1:30 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on template and update channel definition: updates, a word about update channel definition

 

Hi,

 

This makes sense. However, it brings up another interesting problem. How will add-on authors reliably get their add-on releases to the add-on files repo? Currently, it takes someone with read/write access to add the files. Now you have a coordination/timing problem because translators/maintainers keep the website entries up to date while someone else updates the add-on file. In some cases, a request to have an add-on file updated may get lost in the list email. Is there an easier/faster way to get add-on files into the repo?

 

 

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph Lee
Sent: Saturday, August 10, 2019 11:38 PM
To: nvda-devel@groups.io
Subject: [nvda-devel] Add-on template and update channel definition: updates, a word about update channel definition

 

Hi all,

 

Prompted by a discussion on nvda-devel list between Luke Davis and I regarding clarity of update channel definition, coupled with a report from Brian Gaff about some add-ons shipping with update channel set to “stable” for stable releases, I decided to take a look at add-on template repo and make the following change:

 

Update channel definition for build vars dictionary: it’ll say:

 

Add-on update channel (default is None, denoting stable releases, and for development releases, use "dev"; do not change unless you know what you are doing)

 

This should clarify the overall purpose of that manifest key, meaning of “None”, and remind you not to change it unless you are releasing something other than stable releases (i.e. know what you are doing). For the purposes of the template and add-on update checks (currently performed by Add-on Updater, and one day, by NVDA itself unless the scheme changes), setting update channel to None means this is a stable release. Many of you should leave it at default value of None unless you wish to publish development snapshots or need to maintain channels in addition to stable (and/or dev).

 

You might be asking, why None for stable channel? For some of you, this is a repeat, so please bear with me:

 

In 2012, NV Access, together with some contributors, formally defined and implemented NVDA add-on management facility. Prior to NvDA 2012.2, people wishing to extend NVDA would write Python modules and would place them in now deprecated plugin directories (appModules, globalPlugins, brailleDisplayDrivers, synthDrivers inside NVDA user directory). The add-ons subsystem was an attempt to let plugin writers, now commonly known as add-on authors, to package modules inside a compressed (zip) file with an .nvda-addon extension, and once opened by NVDA, add-on packages will be extracted to the newly created “addons” folder inside dedicated subfolders (named according to the add-on name/ID defined in the manifest).

 

In an attempt to coordinate add-on development and collect add-ons from the community and showcase them under one roof, in 2013, the add-ons community mailing list (first generation on Freelists.org) was formed, along with the opening of the NVDA community add-ons website (addons.nvda-project.org). The backbone of the community add-ons website is hosted on an add-on files repository (Bitbucket) in the form of a PHP file that records add-ons hosted on the website and download links for them. When an add-on is approved for community add-ons website, a unique shorthand key was generated (or rather, created) for the add-on and added to the database. Back then, most add-ons were listed as stable versions (with some of them going through development builds), hence the key itself without qualifiers denote stable releases. Subsequently, once the add-on review process was formalized in 2015, more add-ons started using the “-dev” suffix to denote add-ons under development. This process continues today even with the add-ons mailing list moving to Groups.IO in recent years.

 

Then around this time last year (2018), I released Add-on Updater, powered by standalone update facility from StationPlaylist and Windows 10 App Essentials. Borrowing the conventions from many years, this add-on treats add-on keys without qualifiers as stable releases. The add-on contains a map of add-on ID’s to shorthand keys used to look up add-on download links/versions from the add-ons website.

 

The add-on would then calculate the “update channel” value as follows:

 

  1. If an add-on does not define an update channel in the manifest (old add-ons), it is treated as a stable channel. This check is becoming rare.
  2. If the update channel is defined as “None” (technically, it should be None, but ConfigObj turns this into a string), it is a stable channel.
  3. If a different update channel is defined, a qualifier is recorded. Technically, stable channel does have a qualifier, but it is nothing.
  4. Depending on channel obtained, the update channel value (to be passed to a function/thread responsible for connecting to the website and retrieving add-on update information) is either the shorthand key (stable release) or shorthand key + “-“ (hyphen) followed by the name of the custom channel. This is a necessary work because that is how add-on download links are recorded on the website.

 

For example, for Enhanced Touch Gestures, if you are checking for stable releases, the shorthand key (“ets”) alone will be the update channel value; if you are looking for development releases, the value becomes “ets-dev”. Or perhaps I release a custom build of Enhanced Touch Gestures, say “alpha”. The value then becomes “ets-alpha”.

 

So far, it is going well. However, it falls apart when trying to retrieve update information for some add-ons: due to ambiguity present in current add-on template (my sincerest apologies), some authors defined “stable” for stable releases when it should not be defined as such. For example, Toolbars Explorer defines “stable” for stable releases, which means instead of looking at “tbx”, it will actually look up “tbx-stable” which actually doesn’t exist. This is the reason why some of you could not obtain latest stable releases for add-ons like Toolbars Explorer, hence the correction and advice noted above.

 

I will push necessary changes to add-on template tonight.

 

Because it takes time to update all affected add-ons to change their stable channel definitions (coupled with Python 3 porting work), I will not enforce stable release definition change today: I will give you 30 days (until September 10, 2019) to update add-ons. September 10th will also be the day I will release Add-on Updater 19.09 (the second mandatory update for everyone), which will enforce this change; the next version of this add-on, version 19.08.1 scheduled shortly after NVDA 2019.2 stable version is released, will include a compatibility workaround for add-ons affected by stable channel definition problem (note that 19.08.1 will require NVDA 2019.2 due to maintenance policy for Add-on Updater).

 

A huge caveat: the update channel scheme may change once NVDA starts checking for add-on updates on its own (the missing puzzle pieces are server-side work and data exchange mechanisms; others such as update check client and the user interface are done).

 

Thanks, and again, my sincerest apologies for causing ambiguities in the first place and for causing an inconvenience.

Cheers,

Joseph

Re: I suspect auto update is broken on alpha snaps

derek riemer
 

Seems like I haven't gotten any updates in a while.

On Tue, Aug 6, 2019 at 8:13 AM Brian's Mail list account via Groups.Io <bglists=blueyonder.co.uk@groups.io> wrote:
I have to force it to look every time, whereas other branches seem to tell
me almost straight away after loading in the morning.

Could this be the case or is my experience  unusual?

Brian

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






--
Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com




Control Usage Assistant: August 13th development snapshot

 

Hi everyone,

 

Control Usage Assistant August 13th development snapshot is now available. As promised, this one introduces a completely new way of obtaining help, along with a new help message interface.

 

For anyone wishing to take a look at add-on source code: I’d like to inform you that the official source code repo for this add-on has changed. Going forward, all add-on development will take place on GitHub, not Bitbucket. The new (and now official) repo can be found at:

https://github.com/josephsl/controlusageassistant

 

What’s new and different from version 2.5/nightlight: in addition to the new repo, we have:

 

Help messages database, completely redesigned: in version 2.5 and earlier, Control Usage Assistant used object role constants from control types module to retrieve help messages from a central database (really a dictionary), with some scenarios involving an offset (browse mode and messages for controls from some apps, for instance). While it did allow help messages to be defined for well-known controls, it did not leave room for extending the database by adding messages for controls only seen in some apps.

 

The new Control Usage Assistant add-on will now use multiple help message databases to store help messages. There is the default role-based help messages dictionary as before, along with dictionaries to store help messages based on class names for various objects (such as NVDAObjects.behaviors.EditableTextWithSuggestions), including those found in app modules (such as PowerPoint slide shows) included in NVDA. The just released snapshot collects messages found in version 2.5 with one notable omission: help message for read-only edit fields, which I’ll do something about soon.

 

A different procedure for fetching help messages from everywhere: coupled with help message database redesign, a new way to fetch help messages is introduced. Version 2.5 and earlier just looked at object roles and one or two constraints such as whether browse mode is active or dealing with one or two controls from specific apps. Starting with the just released snapshot, NVDA will first look at help messages for objects themselves, followed by one or more constraints such as browse mode, before resorting to role-based help messages.

 

The biggest change from the old releases is how NVDA can figure out help messages for objects. This is done by traversing an object’s method resolution order (MRO), a record of class hierarchy relationships used for attribute lookup and other tasks. For example, for an overlay class defined in an app module which is in turn based on an API class, the class hierarchy (or MRO) for an overlay class starts with the app module one, followed by one or more API level classes, and then proceeding to base NVDA object and its constituent objects such as scriptable object.

 

For each MRO entry, NVDA will look at a string representation of the class name, which is then used as a key to look up object-specific help message. For example, if one is dealing with a custom table object from an app module that is in turn a fake table row object, NVDA can potentially look up help messages for at least two objects: the overlay class found in the app module, and the help message for the fake table row behavior. Only after messages from objects are exhausted will NVDA retrieve help messages based on an object’s role provided that there is one, and if there is no help message whatsoever, NVDA will say, “no help for this control”.

 

During each help message retrieval pass, potential help messages are gathered into a list, including a message about no help for a control. This list is important because it powers the next feature.

 

Same command, different help message interface: the command for getting help on a focused control (NVDA+H) remains the same. But this is where the similarity ends. In version 2.5, NVDA would flash the help message in speech and/or braille. Starting with the just released snapshot, you can (finally) review help messages in a browse mode window. Not only this resolves a problem where you had to press the help command again if you missed the help message, you can now review help messages at your leisure and makes the experience closer to other screen readers.

 

Recall that potential help messages are gathered into a list. The above interface change is why: just before NVDA displays a help message (or several of them) in a browse mode window, entries in that list are transformed into a string. In addition, the help message screen ends with the phrase, “press Escape to close this help screen”. Sounds familiar? This is the exact message borrowed from PAC Mate’s help screen (if you know what I mean), and in some way, is very close to how help screen works for BrailleNote Touch/Touch Plus users (I now am a user of a BrailleNote Touch Plus).

 

How to obtain the development snapshot: there are two ways:

 

  1. Go to community add-ons website (addons.nvda-project.org), select Control Usage Assistant, and select development version link.
  2. If using Add-on Updater, go to NvDA Settings/Add-on Updater, and check “Control Usage Assistant” under “prefer development releases” list and click OK. Then check for add-on updates.

 

How to help: you can help out by sending feedback to me (either on various NVDA lists or privately), or if you are willing, filing issues and pull requests. In particular, I will need help with the following tasks:

 

  1. Code review (for add-ons community): I’ll be sending an official basic review request to add-ons community, because this add-on wasn’t reviewed in a long time.
  2. Adding help messages for specific controls: to do this, after locating the control in question, send me the developer info along with a short help message. If you wish to do so yourself, locate the class MRO for the object, add it to the objects help messages database along with a short help message, and package it as a pull request. If you are adding help messages for roles, be sure to record the role and the help message.
  3. If you are really adventurous and wish to help out with NVDA Core pull request: relevant details can be found at https://github.com/nvaccess/nvda/issues/2699. If you wish to track the work being done, check out josephsl/i2699contextSensitiveHelp branch.

 

Enjoy.

Cheers,

Joseph

Re: Control Usage Assistant: August 13th development snapshot

 

Hi,

For anyone using Add-on Updater: Add-on Update method won’t work because Control Usage Assistant isn’t registered with this add-on. I’ll correct this issue as part of Add-on Updater 19.08.1/19.09. Sorry about that.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph Lee via Groups.Io
Sent: Monday, August 12, 2019 8:24 PM
To: nvda-devel@groups.io
Subject: [nvda-devel] Control Usage Assistant: August 13th development snapshot

 

Hi everyone,

 

Control Usage Assistant August 13th development snapshot is now available. As promised, this one introduces a completely new way of obtaining help, along with a new help message interface.

 

For anyone wishing to take a look at add-on source code: I’d like to inform you that the official source code repo for this add-on has changed. Going forward, all add-on development will take place on GitHub, not Bitbucket. The new (and now official) repo can be found at:

https://github.com/josephsl/controlusageassistant

 

What’s new and different from version 2.5/nightlight: in addition to the new repo, we have:

 

Help messages database, completely redesigned: in version 2.5 and earlier, Control Usage Assistant used object role constants from control types module to retrieve help messages from a central database (really a dictionary), with some scenarios involving an offset (browse mode and messages for controls from some apps, for instance). While it did allow help messages to be defined for well-known controls, it did not leave room for extending the database by adding messages for controls only seen in some apps.

 

The new Control Usage Assistant add-on will now use multiple help message databases to store help messages. There is the default role-based help messages dictionary as before, along with dictionaries to store help messages based on class names for various objects (such as NVDAObjects.behaviors.EditableTextWithSuggestions), including those found in app modules (such as PowerPoint slide shows) included in NVDA. The just released snapshot collects messages found in version 2.5 with one notable omission: help message for read-only edit fields, which I’ll do something about soon.

 

A different procedure for fetching help messages from everywhere: coupled with help message database redesign, a new way to fetch help messages is introduced. Version 2.5 and earlier just looked at object roles and one or two constraints such as whether browse mode is active or dealing with one or two controls from specific apps. Starting with the just released snapshot, NVDA will first look at help messages for objects themselves, followed by one or more constraints such as browse mode, before resorting to role-based help messages.

 

The biggest change from the old releases is how NVDA can figure out help messages for objects. This is done by traversing an object’s method resolution order (MRO), a record of class hierarchy relationships used for attribute lookup and other tasks. For example, for an overlay class defined in an app module which is in turn based on an API class, the class hierarchy (or MRO) for an overlay class starts with the app module one, followed by one or more API level classes, and then proceeding to base NVDA object and its constituent objects such as scriptable object.

 

For each MRO entry, NVDA will look at a string representation of the class name, which is then used as a key to look up object-specific help message. For example, if one is dealing with a custom table object from an app module that is in turn a fake table row object, NVDA can potentially look up help messages for at least two objects: the overlay class found in the app module, and the help message for the fake table row behavior. Only after messages from objects are exhausted will NVDA retrieve help messages based on an object’s role provided that there is one, and if there is no help message whatsoever, NVDA will say, “no help for this control”.

 

During each help message retrieval pass, potential help messages are gathered into a list, including a message about no help for a control. This list is important because it powers the next feature.

 

Same command, different help message interface: the command for getting help on a focused control (NVDA+H) remains the same. But this is where the similarity ends. In version 2.5, NVDA would flash the help message in speech and/or braille. Starting with the just released snapshot, you can (finally) review help messages in a browse mode window. Not only this resolves a problem where you had to press the help command again if you missed the help message, you can now review help messages at your leisure and makes the experience closer to other screen readers.

 

Recall that potential help messages are gathered into a list. The above interface change is why: just before NVDA displays a help message (or several of them) in a browse mode window, entries in that list are transformed into a string. In addition, the help message screen ends with the phrase, “press Escape to close this help screen”. Sounds familiar? This is the exact message borrowed from PAC Mate’s help screen (if you know what I mean), and in some way, is very close to how help screen works for BrailleNote Touch/Touch Plus users (I now am a user of a BrailleNote Touch Plus).

 

How to obtain the development snapshot: there are two ways:

 

  1. Go to community add-ons website (addons.nvda-project.org), select Control Usage Assistant, and select development version link.
  2. If using Add-on Updater, go to NvDA Settings/Add-on Updater, and check “Control Usage Assistant” under “prefer development releases” list and click OK. Then check for add-on updates.

 

How to help: you can help out by sending feedback to me (either on various NVDA lists or privately), or if you are willing, filing issues and pull requests. In particular, I will need help with the following tasks:

 

  1. Code review (for add-ons community): I’ll be sending an official basic review request to add-ons community, because this add-on wasn’t reviewed in a long time.
  2. Adding help messages for specific controls: to do this, after locating the control in question, send me the developer info along with a short help message. If you wish to do so yourself, locate the class MRO for the object, add it to the objects help messages database along with a short help message, and package it as a pull request. If you are adding help messages for roles, be sure to record the role and the help message.
  3. If you are really adventurous and wish to help out with NVDA Core pull request: relevant details can be found at https://github.com/nvaccess/nvda/issues/2699. If you wish to track the work being done, check out josephsl/i2699contextSensitiveHelp branch.

 

Enjoy.

Cheers,

Joseph

how to make a control more accessible

Travis Siegel
 

I have a program I'm working on that has an html view as part of it's main screen.  NVDA reads the text well enough, but it doesn't read it well, in that it breaks lines at unexpected places, and it doesn't show embedded links.  The links isn't really a problem, since I'm not really concerned with links pointing elsewhere anyhow, so that's only a minor issue, but I would like to know how to get NVDA to treat this text area as html text, so it will pay attention to things like headers, and handle the reading a bit better, since now it's reading the text in the window in fragments, and most of the time, those fragments aren't making sense.

Admittedly, I'm not sure how much control I have over the presentation of the text, since it's an imported one, (it calls a windows dll/api to render the text), but when I look at the text line by line, it seems odd to me where NVDA is choosing to put breaks, as well as the fact that the read to end function in NVDA doesn't work.  This at least is one thing I'd really like to fix, since reading is the primary purpose of the app.  I'll include the nvda-F1 text below for the control, perhaps someone here can help me figure out what I need to do to make it work better, whether it be via NVDA plugins, or just adding attributes to the window. There's only so much I can do programatically, since it's an api/dll call, but I'm certainly open to suggestions.  It works as is, but reading the text requires the nvda cursor, not the system one, and I know some folks aren't going to like that, so again, any suggestions would be appreciated.

** cut here **

Developer info for navigator object:
name: u'Copyright'
role: ROLE_DOCUMENT
states: STATE_READONLY
isFocusable: True
hasFocus: False
Python object: <NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible object at 0x05256770>
Python class mro: (<class 'NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible'>, <class 'NVDAObjects.behaviors.EditableTextWithoutAutoSelectDetection'>, <class 'editableText.EditableTextWithoutAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.IAccessible.MSHTML.Body'>, <class 'NVDAObjects.IAccessible.MSHTML.MSHTML'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: RectLTWH(left=412, top=186, width=759, height=628)
value: ''
appModule: <'appModuleHandler' (appName u'reader', process ID 1084) at address 52567b0>
appModule.productName: exception: No version information
appModule.productVersion: exception: No version information
TextInfo: <class 'NVDAObjects.IAccessible.MSHTML.MSHTMLTextInfo'>
windowHandle: 2556670
windowClassName: u'Internet Explorer_Server'
windowControlID: 0
windowStyle: 1442840576
windowThreadID: 6488
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible) ptr=0x9039038 at 5085170>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2556670, objectID=None, childID=0
IAccessible accName: u'Copyright'
IAccessible accRole: ROLE_SYSTEM_PANE
IAccessible accState: STATE_SYSTEM_READONLY, STATE_SYSTEM_VALID (64)
IAccessible accDescription: exception: (-2147467263, 'Not implemented', (None, None, None, 0, None))
IAccessible accValue: u'file://C:\\books\\storybundle\\Adventure\\Singularity - Bill DeSmedt\\OEBPS\\copyright.xhtml'
MSHTML node has ancestor IAccessible: False
MSHTML nodeName: u'body'
** cut here**

I'm actually not sure why it's claiming it's an editable object, because it's most certainly not editable <frown>

The rest seems to be correct though.

Re: how to make a control more accessible

James Scholes
 

It may be helpful in this instance to have a runnable sample. However, straight off the bat, I'd recommend using a more up-to-date rendering engine for your web view (Chromium would be ideal for instance via CEF).

What environment is creating the web view? Is it a standard Win32 app? WPF? WinForms? UWP? Something else?

Regards,

James Scholes

On 13/08/2019 at 9:21 pm, Travis Siegel wrote:
I have a program I'm working on that has an html view as part of it's main screen.  NVDA reads the text well enough, but it doesn't read it well, in that it breaks lines at unexpected places, and it doesn't show embedded links.  The links isn't really a problem, since I'm not really concerned with links pointing elsewhere anyhow, so that's only a minor issue, but I would like to know how to get NVDA to treat this text area as html text, so it will pay attention to things like headers, and handle the reading a bit better, since now it's reading the text in the window in fragments, and most of the time, those fragments aren't making sense.
Admittedly, I'm not sure how much control I have over the presentation of the text, since it's an imported one, (it calls a windows dll/api to render the text), but when I look at the text line by line, it seems odd to me where NVDA is choosing to put breaks, as well as the fact that the read to end function in NVDA doesn't work.  This at least is one thing I'd really like to fix, since reading is the primary purpose of the app.  I'll include the nvda-F1 text below for the control, perhaps someone here can help me figure out what I need to do to make it work better, whether it be via NVDA plugins, or just adding attributes to the window. There's only so much I can do programatically, since it's an api/dll call, but I'm certainly open to suggestions.  It works as is, but reading the text requires the nvda cursor, not the system one, and I know some folks aren't going to like that, so again, any suggestions would be appreciated.
** cut here **
Developer info for navigator object:
name: u'Copyright'
role: ROLE_DOCUMENT
states: STATE_READONLY
isFocusable: True
hasFocus: False
Python object: <NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible object at 0x05256770>
Python class mro: (<class 'NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible'>, <class 'NVDAObjects.behaviors.EditableTextWithoutAutoSelectDetection'>, <class 'editableText.EditableTextWithoutAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.IAccessible.MSHTML.Body'>, <class 'NVDAObjects.IAccessible.MSHTML.MSHTML'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: RectLTWH(left=412, top=186, width=759, height=628)
value: ''
appModule: <'appModuleHandler' (appName u'reader', process ID 1084) at address 52567b0>
appModule.productName: exception: No version information
appModule.productVersion: exception: No version information
TextInfo: <class 'NVDAObjects.IAccessible.MSHTML.MSHTMLTextInfo'>
windowHandle: 2556670
windowClassName: u'Internet Explorer_Server'
windowControlID: 0
windowStyle: 1442840576
windowThreadID: 6488
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible) ptr=0x9039038 at 5085170>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2556670, objectID=None, childID=0
IAccessible accName: u'Copyright'
IAccessible accRole: ROLE_SYSTEM_PANE
IAccessible accState: STATE_SYSTEM_READONLY, STATE_SYSTEM_VALID (64)
IAccessible accDescription: exception: (-2147467263, 'Not implemented', (None, None, None, 0, None))
IAccessible accValue: u'file://C:\\books\\storybundle\\Adventure\\Singularity - Bill DeSmedt\\OEBPS\\copyright.xhtml'
MSHTML node has ancestor IAccessible: False
MSHTML nodeName: u'body'
** cut here**
I'm actually not sure why it's claiming it's an editable object, because it's most certainly not editable <frown>
The rest seems to be correct though.

Re: how to make a control more accessible

Travis Siegel
 

It's actually calling routines in the ATL.DLL windows library file.  Two routines from that dll initialize and process the html view.

The atl.dll file on my windows 8.1 system has a file stamp of 2014, so it's a relatively old dll to be sure.  But, that means this code will work on just about any version of windows, which was my primary intent when I started the project.  Admittedly, I didn't have a clue how to do what I wanted (I.E. embed an html control into my program) when I started, but via some heavy use of google, and a bit of searching on my favorite programming sites, I found this little gem that was only a couple functions, a couple api calls, and poof, exactly what I wanted.

Interestingly enough, under jaws, if I tell jaws that the control is an html area, it behaves properly, (which it most certainly did not do before doing so).  In fact, before I told jaws it was an html control, jaws couldn't even find the text on the screen.  To fix that problem, I had to add the html area to the tab order, then tell jaws it was anhtml control, after that, jaws works like a dream, pressing the button (or hot key) to go to the next chapter starts jaws reading the text automatically just as soon as it comes up on the screen.

I was hoping I could do something similar for NVDA.

Especially, since NVDA doesn't suffer from the issue of not knowing the html control is on the screen, it finds it just fine, and I can even read it, but again, I have to use the numpad keys to work my way through the text.  Interestingly enough, NVDA doesn't seem to know about the various headers, links, and other html elements in the text, but jaws not only sees them, but alows me to click on them as if it were an actual browser.  I'm not real happy with that result, since it means NVDA is being shown up at something it initially has a much better handle on, so if I could tell NVDA this is an html area, and allow it to behave accordingly, I'm fairly certain all would work like a treat.

I just don't know how to do that.

On 8/13/2019 5:50 PM, James Scholes wrote:

It may be helpful in this instance to have a runnable sample. However, straight off the bat, I'd recommend using a more up-to-date rendering engine for your web view (Chromium would be ideal for instance via CEF).

What environment is creating the web view?  Is it a standard Win32 app? WPF?  WinForms?  UWP?  Something else?

Regards,

James Scholes

On 13/08/2019 at 9:21 pm, Travis Siegel wrote:
I have a program I'm working on that has an html view as part of it's main screen.  NVDA reads the text well enough, but it doesn't read it well, in that it breaks lines at unexpected places, and it doesn't show embedded links. The links isn't really a problem, since I'm not really concerned with links pointing elsewhere anyhow, so that's only a minor issue, but I would like to know how to get NVDA to treat this text area as html text, so it will pay attention to things like headers, and handle the reading a bit better, since now it's reading the text in the window in fragments, and most of the time, those fragments aren't making sense.

Admittedly, I'm not sure how much control I have over the presentation of the text, since it's an imported one, (it calls a windows dll/api to render the text), but when I look at the text line by line, it seems odd to me where NVDA is choosing to put breaks, as well as the fact that the read to end function in NVDA doesn't work.  This at least is one thing I'd really like to fix, since reading is the primary purpose of the app.  I'll include the nvda-F1 text below for the control, perhaps someone here can help me figure out what I need to do to make it work better, whether it be via NVDA plugins, or just adding attributes to the window. There's only so much I can do programatically, since it's an api/dll call, but I'm certainly open to suggestions.  It works as is, but reading the text requires the nvda cursor, not the system one, and I know some folks aren't going to like that, so again, any suggestions would be appreciated.

** cut here **

Developer info for navigator object:
name: u'Copyright'
role: ROLE_DOCUMENT
states: STATE_READONLY
isFocusable: True
hasFocus: False
Python object: <NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible object at 0x05256770>
Python class mro: (<class 'NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible'>, <class 'NVDAObjects.behaviors.EditableTextWithoutAutoSelectDetection'>, <class 'editableText.EditableTextWithoutAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.IAccessible.MSHTML.Body'>, <class 'NVDAObjects.IAccessible.MSHTML.MSHTML'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: RectLTWH(left=412, top=186, width=759, height=628)
value: ''
appModule: <'appModuleHandler' (appName u'reader', process ID 1084) at address 52567b0>
appModule.productName: exception: No version information
appModule.productVersion: exception: No version information
TextInfo: <class 'NVDAObjects.IAccessible.MSHTML.MSHTMLTextInfo'>
windowHandle: 2556670
windowClassName: u'Internet Explorer_Server'
windowControlID: 0
windowStyle: 1442840576
windowThreadID: 6488
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible) ptr=0x9039038 at 5085170>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2556670, objectID=None, childID=0
IAccessible accName: u'Copyright'
IAccessible accRole: ROLE_SYSTEM_PANE
IAccessible accState: STATE_SYSTEM_READONLY, STATE_SYSTEM_VALID (64)
IAccessible accDescription: exception: (-2147467263, 'Not implemented', (None, None, None, 0, None))
IAccessible accValue: u'file://C:\\books\\storybundle\\Adventure\\Singularity - Bill DeSmedt\\OEBPS\\copyright.xhtml'
MSHTML node has ancestor IAccessible: False
MSHTML nodeName: u'body'
** cut here**

I'm actually not sure why it's claiming it's an editable object, because it's most certainly not editable <frown>

The rest seems to be correct though.





Re: how to make a control more accessible

James Scholes
 

I don't want to stress overly on this, but when you say "next chapter", it sounds like you're creating some sort of reading software. If it's for eBooks, that really strengthens the case for a better browser engine. There's no reason an embedded Chrome browser can't work across multiple versions of Windows.

Regards,

James Scholes

On 14/08/2019 at 12:34 am, Travis Siegel wrote:
It's actually calling routines in the ATL.DLL windows library file.  Two routines from that dll initialize and process the html view.
The atl.dll file on my windows 8.1 system has a file stamp of 2014, so it's a relatively old dll to be sure.  But, that means this code will work on just about any version of windows, which was my primary intent when I started the project.  Admittedly, I didn't have a clue how to do what I wanted (I.E. embed an html control into my program) when I started, but via some heavy use of google, and a bit of searching on my favorite programming sites, I found this little gem that was only a couple functions, a couple api calls, and poof, exactly what I wanted.
Interestingly enough, under jaws, if I tell jaws that the control is an html area, it behaves properly, (which it most certainly did not do before doing so).  In fact, before I told jaws it was an html control, jaws couldn't even find the text on the screen.  To fix that problem, I had to add the html area to the tab order, then tell jaws it was anhtml control, after that, jaws works like a dream, pressing the button (or hot key) to go to the next chapter starts jaws reading the text automatically just as soon as it comes up on the screen.
I was hoping I could do something similar for NVDA.
Especially, since NVDA doesn't suffer from the issue of not knowing the html control is on the screen, it finds it just fine, and I can even read it, but again, I have to use the numpad keys to work my way through the text.  Interestingly enough, NVDA doesn't seem to know about the various headers, links, and other html elements in the text, but jaws not only sees them, but alows me to click on them as if it were an actual browser.  I'm not real happy with that result, since it means NVDA is being shown up at something it initially has a much better handle on, so if I could tell NVDA this is an html area, and allow it to behave accordingly, I'm fairly certain all would work like a treat.
I just don't know how to do that.
On 8/13/2019 5:50 PM, James Scholes wrote:

It may be helpful in this instance to have a runnable sample. However, straight off the bat, I'd recommend using a more up-to-date rendering engine for your web view (Chromium would be ideal for instance via CEF).

What environment is creating the web view?  Is it a standard Win32 app? WPF?  WinForms?  UWP?  Something else?

Regards,

James Scholes

On 13/08/2019 at 9:21 pm, Travis Siegel wrote:
I have a program I'm working on that has an html view as part of it's main screen.  NVDA reads the text well enough, but it doesn't read it well, in that it breaks lines at unexpected places, and it doesn't show embedded links. The links isn't really a problem, since I'm not really concerned with links pointing elsewhere anyhow, so that's only a minor issue, but I would like to know how to get NVDA to treat this text area as html text, so it will pay attention to things like headers, and handle the reading a bit better, since now it's reading the text in the window in fragments, and most of the time, those fragments aren't making sense.

Admittedly, I'm not sure how much control I have over the presentation of the text, since it's an imported one, (it calls a windows dll/api to render the text), but when I look at the text line by line, it seems odd to me where NVDA is choosing to put breaks, as well as the fact that the read to end function in NVDA doesn't work. This at least is one thing I'd really like to fix, since reading is the primary purpose of the app.  I'll include the nvda-F1 text below for the control, perhaps someone here can help me figure out what I need to do to make it work better, whether it be via NVDA plugins, or just adding attributes to the window. There's only so much I can do programatically, since it's an api/dll call, but I'm certainly open to suggestions.  It works as is, but reading the text requires the nvda cursor, not the system one, and I know some folks aren't going to like that, so again, any suggestions would be appreciated.

** cut here **

Developer info for navigator object:
name: u'Copyright'
role: ROLE_DOCUMENT
states: STATE_READONLY
isFocusable: True
hasFocus: False
Python object: <NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible object at 0x05256770>
Python class mro: (<class 'NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible'>, <class 'NVDAObjects.behaviors.EditableTextWithoutAutoSelectDetection'>, <class 'editableText.EditableTextWithoutAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.IAccessible.MSHTML.Body'>, <class 'NVDAObjects.IAccessible.MSHTML.MSHTML'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: RectLTWH(left=412, top=186, width=759, height=628)
value: ''
appModule: <'appModuleHandler' (appName u'reader', process ID 1084) at address 52567b0>
appModule.productName: exception: No version information
appModule.productVersion: exception: No version information
TextInfo: <class 'NVDAObjects.IAccessible.MSHTML.MSHTMLTextInfo'>
windowHandle: 2556670
windowClassName: u'Internet Explorer_Server'
windowControlID: 0
windowStyle: 1442840576
windowThreadID: 6488
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible) ptr=0x9039038 at 5085170>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2556670, objectID=None, childID=0
IAccessible accName: u'Copyright'
IAccessible accRole: ROLE_SYSTEM_PANE
IAccessible accState: STATE_SYSTEM_READONLY, STATE_SYSTEM_VALID (64)
IAccessible accDescription: exception: (-2147467263, 'Not implemented', (None, None, None, 0, None))
IAccessible accValue: u'file://C:\\books\\storybundle\\Adventure\\Singularity - Bill DeSmedt\\OEBPS\\copyright.xhtml'
MSHTML node has ancestor IAccessible: False
MSHTML nodeName: u'body'
** cut here**

I'm actually not sure why it's claiming it's an editable object, because it's most certainly not editable <frown>

The rest seems to be correct though.






Re: how to make a control more accessible

Brian's Mail list account
 

It seems the implementation is not triggering the creation of the virtual buffer here, which is why its not working.
Brian

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

----- Original Message -----
From: "Travis Siegel" <tsiegel@...>
To: <nvda-devel@groups.io>
Sent: Wednesday, August 14, 2019 12:34 AM
Subject: Re: [nvda-devel] how to make a control more accessible


It's actually calling routines in the ATL.DLL windows library file. Two
routines from that dll initialize and process the html view.

The atl.dll file on my windows 8.1 system has a file stamp of 2014, so
it's a relatively old dll to be sure. But, that means this code will
work on just about any version of windows, which was my primary intent
when I started the project. Admittedly, I didn't have a clue how to do
what I wanted (I.E. embed an html control into my program) when I
started, but via some heavy use of google, and a bit of searching on my
favorite programming sites, I found this little gem that was only a
couple functions, a couple api calls, and poof, exactly what I wanted.

Interestingly enough, under jaws, if I tell jaws that the control is an
html area, it behaves properly, (which it most certainly did not do
before doing so). In fact, before I told jaws it was an html control,
jaws couldn't even find the text on the screen. To fix that problem, I
had to add the html area to the tab order, then tell jaws it was anhtml
control, after that, jaws works like a dream, pressing the button (or
hot key) to go to the next chapter starts jaws reading the text
automatically just as soon as it comes up on the screen.

I was hoping I could do something similar for NVDA.

Especially, since NVDA doesn't suffer from the issue of not knowing the
html control is on the screen, it finds it just fine, and I can even
read it, but again, I have to use the numpad keys to work my way through
the text. Interestingly enough, NVDA doesn't seem to know about the
various headers, links, and other html elements in the text, but jaws
not only sees them, but alows me to click on them as if it were an
actual browser. I'm not real happy with that result, since it means
NVDA is being shown up at something it initially has a much better
handle on, so if I could tell NVDA this is an html area, and allow it to
behave accordingly, I'm fairly certain all would work like a treat.

I just don't know how to do that.


On 8/13/2019 5:50 PM, James Scholes wrote:

It may be helpful in this instance to have a runnable sample. However, straight off the bat, I'd recommend using a more up-to-date rendering engine for your web view (Chromium would be ideal for instance via CEF).

What environment is creating the web view? Is it a standard Win32 app? WPF? WinForms? UWP? Something else?

Regards,

James Scholes

On 13/08/2019 at 9:21 pm, Travis Siegel wrote:
I have a program I'm working on that has an html view as part of it's main screen. NVDA reads the text well enough, but it doesn't read it well, in that it breaks lines at unexpected places, and it doesn't show embedded links. The links isn't really a problem, since I'm not really concerned with links pointing elsewhere anyhow, so that's only a minor issue, but I would like to know how to get NVDA to treat this text area as html text, so it will pay attention to things like headers, and handle the reading a bit better, since now it's reading the text in the window in fragments, and most of the time, those fragments aren't making sense.

Admittedly, I'm not sure how much control I have over the presentation of the text, since it's an imported one, (it calls a windows dll/api to render the text), but when I look at the text line by line, it seems odd to me where NVDA is choosing to put breaks, as well as the fact that the read to end function in NVDA doesn't work. This at least is one thing I'd really like to fix, since reading is the primary purpose of the app. I'll include the nvda-F1 text below for the control, perhaps someone here can help me figure out what I need to do to make it work better, whether it be via NVDA plugins, or just adding attributes to the window. There's only so much I can do programatically, since it's an api/dll call, but I'm certainly open to suggestions. It works as is, but reading the text requires the nvda cursor, not the system one, and I know some folks aren't going to like that, so again, any suggestions would be appreciated.

** cut here **

Developer info for navigator object:
name: u'Copyright'
role: ROLE_DOCUMENT
states: STATE_READONLY
isFocusable: True
hasFocus: False
Python object: <NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible object at 0x05256770>
Python class mro: (<class 'NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible'>, <class 'NVDAObjects.behaviors.EditableTextWithoutAutoSelectDetection'>, <class 'editableText.EditableTextWithoutAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.IAccessible.MSHTML.Body'>, <class 'NVDAObjects.IAccessible.MSHTML.MSHTML'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: RectLTWH(left=412, top=186, width=759, height=628)
value: ''
appModule: <'appModuleHandler' (appName u'reader', process ID 1084) at address 52567b0>
appModule.productName: exception: No version information
appModule.productVersion: exception: No version information
TextInfo: <class 'NVDAObjects.IAccessible.MSHTML.MSHTMLTextInfo'>
windowHandle: 2556670
windowClassName: u'Internet Explorer_Server'
windowControlID: 0
windowStyle: 1442840576
windowThreadID: 6488
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible) ptr=0x9039038 at 5085170>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2556670, objectID=None, childID=0
IAccessible accName: u'Copyright'
IAccessible accRole: ROLE_SYSTEM_PANE
IAccessible accState: STATE_SYSTEM_READONLY, STATE_SYSTEM_VALID (64)
IAccessible accDescription: exception: (-2147467263, 'Not implemented', (None, None, None, 0, None))
IAccessible accValue: u'file://C:\\books\\storybundle\\Adventure\\Singularity - Bill DeSmedt\\OEBPS\\copyright.xhtml'
MSHTML node has ancestor IAccessible: False
MSHTML nodeName: u'body'
** cut here**

I'm actually not sure why it's claiming it's an editable object, because it's most certainly not editable <frown>

The rest seems to be correct though.






Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available

 

Hi all,

 

A few days ago I wrote that I’ll release Python 3 alpha versions of some of my add-ons (ones with Python 3 strict branch or requiring NVDA 2019.3 technologies) shortly after NVDA 2019.2 sees the light of day. Now that it did, I’m releasing Python 3 alpha versions of the following add-ons:

 

 

 

IMPORTANT NOTES:

  1. These add-ons REQUIRE NVDA 2019.3 alpha.
  2. Update check for these add-ons will not be possible – Add-on Updater doesn’t know how to check for updates for Python 3 alpha builds, and that is intentional.
  3. After installing these add-ons, there is no going back. For this reason, please use another copy of NVDA for testing these add-ons.
  4. For StationPlaylist users: the Python 3 alpha builds of this add-on will be released only if significant changes were made to SPL add-on that warrants testing with NVDA 2019.3 alpha. Those on development snapshots (regular ones, that is) will not see Python 3 version of SPL add-on until shortly after 2019.3 RC is released; a limited field testing will take place during 2019.3 beta cycle. Due to pickle protocol changes, after installing today’s alpha snapshot, there is no going back.
  5. For Resource Monitor users: you’ll notice smaller download size due to removal of Python 2 version of psutil. Python 3 alpha version of Resource Monitor will bundle Python 3 version of psutil.
  6. There will be more add-ons joining the Python 3 alpha testing program, either because they will be optimized for Python 3 (such as SystrayList), supports newer versions of NVDA (such as Windows 10 App Essentials), or a combination of these.

 

Any feedback on my add-ons participating in Python 3 alpha testing are welcome.

Cheers,

Joseph

Re: how to make a control more accessible

Travis Siegel
 

Yeah, but the problem is that if I use an embedded chrome browser, I need to ship extra crap with my program, and from my experience, the more stuff you include, the more problems people have with it, (because they have a tendency to knowingly (or otherwise) break things.  I'd much rather use a windows embedded control even if it isn't the best possible solution, because then there's fewer things to break.

And, yes, it's ebook reading software.  I don't know about anyone else, but I got fed up with the inaccessible epub reading software out there, because I couldn't find a single epub reader that did the job simply, easily, and was 100 percent accessible.  I normally just extract the epub files myself, and read them in my browser, but I've run across a few epub files that have what amounts to random garbage for file names, and determining the order of reading was problematic, so that kind of nixed the browser reading process I usually use.  Those are the main reason I set out to write this piece of software.

If nobody else uses it, that's ok with me, it solves a problem I have, and really, that's all that's necessary.  I'm just trying to make it more user friendly, so that I can release it and allow others to use it as well.

If I can't find a way to do that, then I'll leave it as is, but I just know I'm going to get complaints because it doesn't read automatically, or because it doesn't handle broken epub files, or because it doesn't read outloud, or any number of other issues I haven't even thought of yet.

Folks really tend to blow up if it works well for one screen reader, but not for another one, so that's why the questions here.  I have no trouble making it work perfectly with jaws, and I'd really like to have that same transparency with NVDA, since that's my screen reader of choice, and it's kind of sad that I'd release a program that works better on a screen reader I don't even use.

On 8/14/2019 3:55 AM, James Scholes wrote:

I don't want to stress overly on this, but when you say "next chapter", it sounds like you're creating some sort of reading software.  If it's for eBooks, that really strengthens the case for a better browser engine.  There's no reason an embedded Chrome browser can't work across multiple versions of Windows.

Regards,

James Scholes

On 14/08/2019 at 12:34 am, Travis Siegel wrote:
It's actually calling routines in the ATL.DLL windows library file.  Two routines from that dll initialize and process the html view.

The atl.dll file on my windows 8.1 system has a file stamp of 2014, so it's a relatively old dll to be sure.  But, that means this code will work on just about any version of windows, which was my primary intent when I started the project.  Admittedly, I didn't have a clue how to do what I wanted (I.E. embed an html control into my program) when I started, but via some heavy use of google, and a bit of searching on my favorite programming sites, I found this little gem that was only a couple functions, a couple api calls, and poof, exactly what I wanted.

Interestingly enough, under jaws, if I tell jaws that the control is an html area, it behaves properly, (which it most certainly did not do before doing so).  In fact, before I told jaws it was an html control, jaws couldn't even find the text on the screen.  To fix that problem, I had to add the html area to the tab order, then tell jaws it was anhtml control, after that, jaws works like a dream, pressing the button (or hot key) to go to the next chapter starts jaws reading the text automatically just as soon as it comes up on the screen.

I was hoping I could do something similar for NVDA.

Especially, since NVDA doesn't suffer from the issue of not knowing the html control is on the screen, it finds it just fine, and I can even read it, but again, I have to use the numpad keys to work my way through the text.  Interestingly enough, NVDA doesn't seem to know about the various headers, links, and other html elements in the text, but jaws not only sees them, but alows me to click on them as if it were an actual browser.  I'm not real happy with that result, since it means NVDA is being shown up at something it initially has a much better handle on, so if I could tell NVDA this is an html area, and allow it to behave accordingly, I'm fairly certain all would work like a treat.

I just don't know how to do that.


On 8/13/2019 5:50 PM, James Scholes wrote:

It may be helpful in this instance to have a runnable sample. However, straight off the bat, I'd recommend using a more up-to-date rendering engine for your web view (Chromium would be ideal for instance via CEF).

What environment is creating the web view?  Is it a standard Win32 app? WPF?  WinForms?  UWP?  Something else?

Regards,

James Scholes

On 13/08/2019 at 9:21 pm, Travis Siegel wrote:
I have a program I'm working on that has an html view as part of it's main screen.  NVDA reads the text well enough, but it doesn't read it well, in that it breaks lines at unexpected places, and it doesn't show embedded links. The links isn't really a problem, since I'm not really concerned with links pointing elsewhere anyhow, so that's only a minor issue, but I would like to know how to get NVDA to treat this text area as html text, so it will pay attention to things like headers, and handle the reading a bit better, since now it's reading the text in the window in fragments, and most of the time, those fragments aren't making sense.

Admittedly, I'm not sure how much control I have over the presentation of the text, since it's an imported one, (it calls a windows dll/api to render the text), but when I look at the text line by line, it seems odd to me where NVDA is choosing to put breaks, as well as the fact that the read to end function in NVDA doesn't work. This at least is one thing I'd really like to fix, since reading is the primary purpose of the app.  I'll include the nvda-F1 text below for the control, perhaps someone here can help me figure out what I need to do to make it work better, whether it be via NVDA plugins, or just adding attributes to the window. There's only so much I can do programatically, since it's an api/dll call, but I'm certainly open to suggestions.  It works as is, but reading the text requires the nvda cursor, not the system one, and I know some folks aren't going to like that, so again, any suggestions would be appreciated.

** cut here **

Developer info for navigator object:
name: u'Copyright'
role: ROLE_DOCUMENT
states: STATE_READONLY
isFocusable: True
hasFocus: False
Python object: <NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible object at 0x05256770>
Python class mro: (<class 'NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible'>, <class 'NVDAObjects.behaviors.EditableTextWithoutAutoSelectDetection'>, <class 'editableText.EditableTextWithoutAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.IAccessible.MSHTML.Body'>, <class 'NVDAObjects.IAccessible.MSHTML.MSHTML'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: RectLTWH(left=412, top=186, width=759, height=628)
value: ''
appModule: <'appModuleHandler' (appName u'reader', process ID 1084) at address 52567b0>
appModule.productName: exception: No version information
appModule.productVersion: exception: No version information
TextInfo: <class 'NVDAObjects.IAccessible.MSHTML.MSHTMLTextInfo'>
windowHandle: 2556670
windowClassName: u'Internet Explorer_Server'
windowControlID: 0
windowStyle: 1442840576
windowThreadID: 6488
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible) ptr=0x9039038 at 5085170>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2556670, objectID=None, childID=0
IAccessible accName: u'Copyright'
IAccessible accRole: ROLE_SYSTEM_PANE
IAccessible accState: STATE_SYSTEM_READONLY, STATE_SYSTEM_VALID (64)
IAccessible accDescription: exception: (-2147467263, 'Not implemented', (None, None, None, 0, None))
IAccessible accValue: u'file://C:\\books\\storybundle\\Adventure\\Singularity - Bill DeSmedt\\OEBPS\\copyright.xhtml'
MSHTML node has ancestor IAccessible: False
MSHTML nodeName: u'body'
** cut here**

I'm actually not sure why it's claiming it's an editable object, because it's most certainly not editable <frown>

The rest seems to be correct though.









Re: how to make a control more accessible

Tyler Spivey
 

If the HTML control works with JAWS and lets you use browse mode, then I would argue that it was a bug in NVDA.
Submit a simple test program with one HTMl control as an issue and see what happens.

On 8/14/2019 11:47 AM, Travis Siegel wrote:
Yeah, but the problem is that if I use an embedded chrome browser, I need to ship extra crap with my program, and from my experience, the more stuff you include, the more problems people have with it, (because they have a tendency to knowingly (or otherwise) break things.  I'd much rather use a windows embedded control even if it isn't the best possible solution, because then there's fewer things to break.
And, yes, it's ebook reading software.  I don't know about anyone else, but I got fed up with the inaccessible epub reading software out there, because I couldn't find a single epub reader that did the job simply, easily, and was 100 percent accessible.  I normally just extract the epub files myself, and read them in my browser, but I've run across a few epub files that have what amounts to random garbage for file names, and determining the order of reading was problematic, so that kind of nixed the browser reading process I usually use.  Those are the main reason I set out to write this piece of software.
If nobody else uses it, that's ok with me, it solves a problem I have, and really, that's all that's necessary.  I'm just trying to make it more user friendly, so that I can release it and allow others to use it as well.
If I can't find a way to do that, then I'll leave it as is, but I just know I'm going to get complaints because it doesn't read automatically, or because it doesn't handle broken epub files, or because it doesn't read outloud, or any number of other issues I haven't even thought of yet.
Folks really tend to blow up if it works well for one screen reader, but not for another one, so that's why the questions here.  I have no trouble making it work perfectly with jaws, and I'd really like to have that same transparency with NVDA, since that's my screen reader of choice, and it's kind of sad that I'd release a program that works better on a screen reader I don't even use.
On 8/14/2019 3:55 AM, James Scholes wrote:

I don't want to stress overly on this, but when you say "next chapter", it sounds like you're creating some sort of reading software.  If it's for eBooks, that really strengthens the case for a better browser engine.  There's no reason an embedded Chrome browser can't work across multiple versions of Windows.

Regards,

James Scholes

On 14/08/2019 at 12:34 am, Travis Siegel wrote:
It's actually calling routines in the ATL.DLL windows library file. Two routines from that dll initialize and process the html view.

The atl.dll file on my windows 8.1 system has a file stamp of 2014, so it's a relatively old dll to be sure.  But, that means this code will work on just about any version of windows, which was my primary intent when I started the project.  Admittedly, I didn't have a clue how to do what I wanted (I.E. embed an html control into my program) when I started, but via some heavy use of google, and a bit of searching on my favorite programming sites, I found this little gem that was only a couple functions, a couple api calls, and poof, exactly what I wanted.

Interestingly enough, under jaws, if I tell jaws that the control is an html area, it behaves properly, (which it most certainly did not do before doing so).  In fact, before I told jaws it was an html control, jaws couldn't even find the text on the screen.  To fix that problem, I had to add the html area to the tab order, then tell jaws it was anhtml control, after that, jaws works like a dream, pressing the button (or hot key) to go to the next chapter starts jaws reading the text automatically just as soon as it comes up on the screen.

I was hoping I could do something similar for NVDA.

Especially, since NVDA doesn't suffer from the issue of not knowing the html control is on the screen, it finds it just fine, and I can even read it, but again, I have to use the numpad keys to work my way through the text.  Interestingly enough, NVDA doesn't seem to know about the various headers, links, and other html elements in the text, but jaws not only sees them, but alows me to click on them as if it were an actual browser.  I'm not real happy with that result, since it means NVDA is being shown up at something it initially has a much better handle on, so if I could tell NVDA this is an html area, and allow it to behave accordingly, I'm fairly certain all would work like a treat.

I just don't know how to do that.


On 8/13/2019 5:50 PM, James Scholes wrote:

It may be helpful in this instance to have a runnable sample. However, straight off the bat, I'd recommend using a more up-to-date rendering engine for your web view (Chromium would be ideal for instance via CEF).

What environment is creating the web view?  Is it a standard Win32 app? WPF?  WinForms?  UWP?  Something else?

Regards,

James Scholes

On 13/08/2019 at 9:21 pm, Travis Siegel wrote:
I have a program I'm working on that has an html view as part of it's main screen.  NVDA reads the text well enough, but it doesn't read it well, in that it breaks lines at unexpected places, and it doesn't show embedded links. The links isn't really a problem, since I'm not really concerned with links pointing elsewhere anyhow, so that's only a minor issue, but I would like to know how to get NVDA to treat this text area as html text, so it will pay attention to things like headers, and handle the reading a bit better, since now it's reading the text in the window in fragments, and most of the time, those fragments aren't making sense.

Admittedly, I'm not sure how much control I have over the presentation of the text, since it's an imported one, (it calls a windows dll/api to render the text), but when I look at the text line by line, it seems odd to me where NVDA is choosing to put breaks, as well as the fact that the read to end function in NVDA doesn't work. This at least is one thing I'd really like to fix, since reading is the primary purpose of the app.  I'll include the nvda-F1 text below for the control, perhaps someone here can help me figure out what I need to do to make it work better, whether it be via NVDA plugins, or just adding attributes to the window. There's only so much I can do programatically, since it's an api/dll call, but I'm certainly open to suggestions.  It works as is, but reading the text requires the nvda cursor, not the system one, and I know some folks aren't going to like that, so again, any suggestions would be appreciated.

** cut here **

Developer info for navigator object:
name: u'Copyright'
role: ROLE_DOCUMENT
states: STATE_READONLY
isFocusable: True
hasFocus: False
Python object: <NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible object at 0x05256770>
Python class mro: (<class 'NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible'>, <class 'NVDAObjects.behaviors.EditableTextWithoutAutoSelectDetection'>, <class 'editableText.EditableTextWithoutAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.IAccessible.MSHTML.Body'>, <class 'NVDAObjects.IAccessible.MSHTML.MSHTML'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: RectLTWH(left=412, top=186, width=759, height=628)
value: ''
appModule: <'appModuleHandler' (appName u'reader', process ID 1084) at address 52567b0>
appModule.productName: exception: No version information
appModule.productVersion: exception: No version information
TextInfo: <class 'NVDAObjects.IAccessible.MSHTML.MSHTMLTextInfo'>
windowHandle: 2556670
windowClassName: u'Internet Explorer_Server'
windowControlID: 0
windowStyle: 1442840576
windowThreadID: 6488
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible) ptr=0x9039038 at 5085170>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2556670, objectID=None, childID=0
IAccessible accName: u'Copyright'
IAccessible accRole: ROLE_SYSTEM_PANE
IAccessible accState: STATE_SYSTEM_READONLY, STATE_SYSTEM_VALID (64)
IAccessible accDescription: exception: (-2147467263, 'Not implemented', (None, None, None, 0, None))
IAccessible accValue: u'file://C:\\books\\storybundle\\Adventure\\Singularity - Bill DeSmedt\\OEBPS\\copyright.xhtml'
MSHTML node has ancestor IAccessible: False
MSHTML nodeName: u'body'
** cut here**

I'm actually not sure why it's claiming it's an editable object, because it's most certainly not editable <frown>

The rest seems to be correct though.










Re: Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available

Brian's Mail list account
 

OK one query. I've updated nothing on the alpha branch since yesterday, but booting up alpha today gives...
initializing updateCheck
INFO - core.main (20:07:28.700):
NVDA initialized
DEBUG - core.main (20:07:28.701):
entering wx application main loop
INFO - updateCheck.AutoUpdateChecker._started (20:07:28.712):
Performing automatic update check
IO - speech.speak (20:07:28.739):
Speaking [LangChangeCommand ('en_GB'), 'Taskbar']
DEBUGWARNING - characterProcessing._getSpeechSymbolsForLocale (20:07:28.740):
No CLDR data for locale en_GB
ERROR - stderr (20:07:29.565):
Exception in thread Thread-23:
Traceback (most recent call last):
File "threading.pyc", line 926, in _bootstrap_inner
File "threading.pyc", line 870, in run
File "C:\nvda extra\userConfig\addons\addonUpdater\globalPlugins\addonUpdater\addonHandlerEx.py", line 134, in fetchAddonInfo
addonUrl = results[addonKey]
KeyError: 'tbx-stable'
DEBUG - windowUtils.getWindowScalingFactor (20:07:30.091):
GetDpiForWindow failed, using GetDeviceCaps instead
IO - inputCore.InputManager.executeGesture (20:07:33.454):
Input: kb(desktop):downArrow
IO - inputCore.InputManager.executeGesture (20:07:33.998):
Input: kb(desktop):upArrow
IO - inputCore.InputManager.executeGesture (20:07:36.174):
Input: kb(desktop):downArrow
IO - inputCore.InputManager.executeGesture (20:07:37.054):
Input: kb(desktop):alt+tab
IO - speech.speak (20:07:37.117):
Speaking [LangChangeCommand ('en_GB'), '2nvda develop list - Outlook Express - Brians lists account BGlists icon 1 of 2']
IO - speech.speak (20:07:37.742):
Speaking [LangChangeCommand ('en_GB'), '2nvda develop list - Outlook Express - Brians lists account BGlists']
IO - speech.speak (20:07:37.842):
Speaking [LangChangeCommand ('en_GB'), 'Outlook Express Message List list']
IO - speech.speak (20:07:37.940):
Speaking [LangChangeCommand ('en_GB'), "From: Joseph Lee; Subject: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available; Received: 14/08/2019 18:23 1392 of

Is this due to the way you are stopping Python 3 add ons in add on updater?


Brian

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

----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Wednesday, August 14, 2019 6:23 PM
Subject: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available


Hi all,



A few days ago I wrote that I'll release Python 3 alpha versions of some of
my add-ons (ones with Python 3 strict branch or requiring NVDA 2019.3
technologies) shortly after NVDA 2019.2 sees the light of day. Now that it
did, I'm releasing Python 3 alpha versions of the following add-ons:



* Resource Monitor:
http://www.josephsl.net/files/nvdaaddons/py3/resourceMonitor-20190814-py3.nv
da-addon
* StationPlaylist:
http://www.josephsl.net/files/nvdaaddons/py3/stationPlaylist-20190814-py3.nv
da-addon





IMPORTANT NOTES:

1. These add-ons REQUIRE NVDA 2019.3 alpha.
2. Update check for these add-ons will not be possible - Add-on Updater
doesn't know how to check for updates for Python 3 alpha builds, and that is
intentional.
3. After installing these add-ons, there is no going back. For this
reason, please use another copy of NVDA for testing these add-ons.
4. For StationPlaylist users: the Python 3 alpha builds of this add-on
will be released only if significant changes were made to SPL add-on that
warrants testing with NVDA 2019.3 alpha. Those on development snapshots
(regular ones, that is) will not see Python 3 version of SPL add-on until
shortly after 2019.3 RC is released; a limited field testing will take place
during 2019.3 beta cycle. Due to pickle protocol changes, after installing
today's alpha snapshot, there is no going back.
5. For Resource Monitor users: you'll notice smaller download size due
to removal of Python 2 version of psutil. Python 3 alpha version of Resource
Monitor will bundle Python 3 version of psutil.
6. There will be more add-ons joining the Python 3 alpha testing
program, either because they will be optimized for Python 3 (such as
SystrayList), supports newer versions of NVDA (such as Windows 10 App
Essentials), or a combination of these.



Any feedback on my add-ons participating in Python 3 alpha testing are
welcome.

Cheers,

Joseph



Re: Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available

Brian's Mail list account
 

Erm if you are running both versions of resource monitor together now, why would you change that as leaving the python 2 parts would presumably mean you only need one copy of that add on if you have old and new versions of nvda in use. I know a lot of people who keep older versions around as well.
Is this not making more work for everyone and yourself?
Brian

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

----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Wednesday, August 14, 2019 6:23 PM
Subject: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available


Hi all,



A few days ago I wrote that I'll release Python 3 alpha versions of some of
my add-ons (ones with Python 3 strict branch or requiring NVDA 2019.3
technologies) shortly after NVDA 2019.2 sees the light of day. Now that it
did, I'm releasing Python 3 alpha versions of the following add-ons:



* Resource Monitor:
http://www.josephsl.net/files/nvdaaddons/py3/resourceMonitor-20190814-py3.nv
da-addon
* StationPlaylist:
http://www.josephsl.net/files/nvdaaddons/py3/stationPlaylist-20190814-py3.nv
da-addon





IMPORTANT NOTES:

1. These add-ons REQUIRE NVDA 2019.3 alpha.
2. Update check for these add-ons will not be possible - Add-on Updater
doesn't know how to check for updates for Python 3 alpha builds, and that is
intentional.
3. After installing these add-ons, there is no going back. For this
reason, please use another copy of NVDA for testing these add-ons.
4. For StationPlaylist users: the Python 3 alpha builds of this add-on
will be released only if significant changes were made to SPL add-on that
warrants testing with NVDA 2019.3 alpha. Those on development snapshots
(regular ones, that is) will not see Python 3 version of SPL add-on until
shortly after 2019.3 RC is released; a limited field testing will take place
during 2019.3 beta cycle. Due to pickle protocol changes, after installing
today's alpha snapshot, there is no going back.
5. For Resource Monitor users: you'll notice smaller download size due
to removal of Python 2 version of psutil. Python 3 alpha version of Resource
Monitor will bundle Python 3 version of psutil.
6. There will be more add-ons joining the Python 3 alpha testing
program, either because they will be optimized for Python 3 (such as
SystrayList), supports newer versions of NVDA (such as Windows 10 App
Essentials), or a combination of these.



Any feedback on my add-ons participating in Python 3 alpha testing are
welcome.

Cheers,

Joseph



Re: Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available

 

Hi,
The traceback? No, that one (again) has nothing to do with Python 3 alpha
and inability to update them via Add-on updater at this time. Although I
might be able to resolve issues with add-ons using update channel manifest
key in odd ways from the server side, I prefer to let authors handle this
themselves. As I wrote before, I'll provide a way to let outdated add-ons
with odd update channel behavior receive updates via Add-on Updater in
upcoming version 19.08.1 and 19.09.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Brian's Mail
list account via Groups.Io
Sent: Wednesday, August 14, 2019 12:12 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3
alpha builds of Resource Monitor and StationPlaylist are now available

OK one query. I've updated nothing on the alpha branch since yesterday, but
booting up alpha today gives...
initializing updateCheck
INFO - core.main (20:07:28.700):
NVDA initialized
DEBUG - core.main (20:07:28.701):
entering wx application main loop
INFO - updateCheck.AutoUpdateChecker._started (20:07:28.712):
Performing automatic update check
IO - speech.speak (20:07:28.739):
Speaking [LangChangeCommand ('en_GB'), 'Taskbar'] DEBUGWARNING -
characterProcessing._getSpeechSymbolsForLocale
(20:07:28.740):
No CLDR data for locale en_GB
ERROR - stderr (20:07:29.565):
Exception in thread Thread-23:
Traceback (most recent call last):
File "threading.pyc", line 926, in _bootstrap_inner
File "threading.pyc", line 870, in run
File "C:\nvda
extra\userConfig\addons\addonUpdater\globalPlugins\addonUpdater\addonHandler
Ex.py",
line 134, in fetchAddonInfo
addonUrl = results[addonKey]
KeyError: 'tbx-stable'
DEBUG - windowUtils.getWindowScalingFactor (20:07:30.091):
GetDpiForWindow failed, using GetDeviceCaps instead IO -
inputCore.InputManager.executeGesture (20:07:33.454):
Input: kb(desktop):downArrow
IO - inputCore.InputManager.executeGesture (20:07:33.998):
Input: kb(desktop):upArrow
IO - inputCore.InputManager.executeGesture (20:07:36.174):
Input: kb(desktop):downArrow
IO - inputCore.InputManager.executeGesture (20:07:37.054):
Input: kb(desktop):alt+tab
IO - speech.speak (20:07:37.117):
Speaking [LangChangeCommand ('en_GB'), '2nvda develop list - Outlook Express
- Brians lists account BGlists icon 1 of 2'] IO - speech.speak
(20:07:37.742):
Speaking [LangChangeCommand ('en_GB'), '2nvda develop list - Outlook Express
- Brians lists account BGlists'] IO - speech.speak (20:07:37.842):
Speaking [LangChangeCommand ('en_GB'), 'Outlook Express Message List list']
IO - speech.speak (20:07:37.940):
Speaking [LangChangeCommand ('en_GB'), "From: Joseph Lee; Subject:
[nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of
Resource Monitor and StationPlaylist are now available; Received: 14/08/2019
18:23 1392 of

Is this due to the way you are stopping Python 3 add ons in add on updater?


Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Wednesday, August 14, 2019 6:23 PM
Subject: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha
builds of Resource Monitor and StationPlaylist are now available


Hi all,



A few days ago I wrote that I'll release Python 3 alpha versions of
some of my add-ons (ones with Python 3 strict branch or requiring NVDA
2019.3
technologies) shortly after NVDA 2019.2 sees the light of day. Now
that it did, I'm releasing Python 3 alpha versions of the following
add-ons:



* Resource Monitor:
http://www.josephsl.net/files/nvdaaddons/py3/resourceMonitor-20190814-
py3.nv
da-addon
* StationPlaylist:
http://www.josephsl.net/files/nvdaaddons/py3/stationPlaylist-20190814-
py3.nv
da-addon





IMPORTANT NOTES:

1. These add-ons REQUIRE NVDA 2019.3 alpha.
2. Update check for these add-ons will not be possible - Add-on
Updater doesn't know how to check for updates for Python 3 alpha
builds, and that is intentional.
3. After installing these add-ons, there is no going back. For this
reason, please use another copy of NVDA for testing these add-ons.
4. For StationPlaylist users: the Python 3 alpha builds of this add-on
will be released only if significant changes were made to SPL add-on
that warrants testing with NVDA 2019.3 alpha. Those on development
snapshots (regular ones, that is) will not see Python 3 version of SPL
add-on until shortly after 2019.3 RC is released; a limited field
testing will take place during 2019.3 beta cycle. Due to pickle
protocol changes, after installing today's alpha snapshot, there is no
going back.
5. For Resource Monitor users: you'll notice smaller download size due
to removal of Python 2 version of psutil. Python 3 alpha version of
Resource Monitor will bundle Python 3 version of psutil.
6. There will be more add-ons joining the Python 3 alpha testing
program, either because they will be optimized for Python 3 (such as
SystrayList), supports newer versions of NVDA (such as Windows 10 App
Essentials), or a combination of these.



Any feedback on my add-ons participating in Python 3 alpha testing are
welcome.

Cheers,

Joseph




Re: Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available

Brian's Mail list account
 

I have now downloaded the latest alpha and that error has not reappeared.

Brian

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

----- Original Message -----
From: "Brian's Mail list account via Groups.Io" <bglists=blueyonder.co.uk@groups.io>
To: <nvda-devel@groups.io>
Sent: Wednesday, August 14, 2019 8:19 PM
Subject: Re: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available


Erm if you are running both versions of resource monitor together now, why would you change that as leaving the python 2 parts would presumably mean you only need one copy of that add on if you have old and new versions of nvda in use. I know a lot of people who keep older versions around as well.
Is this not making more work for everyone and yourself?
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Wednesday, August 14, 2019 6:23 PM
Subject: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available


Hi all,



A few days ago I wrote that I'll release Python 3 alpha versions of some of
my add-ons (ones with Python 3 strict branch or requiring NVDA 2019.3
technologies) shortly after NVDA 2019.2 sees the light of day. Now that it
did, I'm releasing Python 3 alpha versions of the following add-ons:



* Resource Monitor:
http://www.josephsl.net/files/nvdaaddons/py3/resourceMonitor-20190814-py3.nv
da-addon
* StationPlaylist:
http://www.josephsl.net/files/nvdaaddons/py3/stationPlaylist-20190814-py3.nv
da-addon





IMPORTANT NOTES:

1. These add-ons REQUIRE NVDA 2019.3 alpha.
2. Update check for these add-ons will not be possible - Add-on Updater
doesn't know how to check for updates for Python 3 alpha builds, and that is
intentional.
3. After installing these add-ons, there is no going back. For this
reason, please use another copy of NVDA for testing these add-ons.
4. For StationPlaylist users: the Python 3 alpha builds of this add-on
will be released only if significant changes were made to SPL add-on that
warrants testing with NVDA 2019.3 alpha. Those on development snapshots
(regular ones, that is) will not see Python 3 version of SPL add-on until
shortly after 2019.3 RC is released; a limited field testing will take place
during 2019.3 beta cycle. Due to pickle protocol changes, after installing
today's alpha snapshot, there is no going back.
5. For Resource Monitor users: you'll notice smaller download size due
to removal of Python 2 version of psutil. Python 3 alpha version of Resource
Monitor will bundle Python 3 version of psutil.
6. There will be more add-ons joining the Python 3 alpha testing
program, either because they will be optimized for Python 3 (such as
SystrayList), supports newer versions of NVDA (such as Windows 10 App
Essentials), or a combination of these.



Any feedback on my add-ons participating in Python 3 alpha testing are
welcome.

Cheers,

Joseph




Re: Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available

Brian's Mail list account
 

It seems to have sorted it out after the alpha update. I guess having both python 2 and 3 versions of nvda on this windows 7 machine might be an issue from time to time. Also still no auto update on alpha snaps, it says its checking but never does till I force it from the help menu.
Brian

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

----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Wednesday, August 14, 2019 8:21 PM
Subject: Re: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available


Hi,
The traceback? No, that one (again) has nothing to do with Python 3 alpha
and inability to update them via Add-on updater at this time. Although I
might be able to resolve issues with add-ons using update channel manifest
key in odd ways from the server side, I prefer to let authors handle this
themselves. As I wrote before, I'll provide a way to let outdated add-ons
with odd update channel behavior receive updates via Add-on Updater in
upcoming version 19.08.1 and 19.09.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Brian's Mail
list account via Groups.Io
Sent: Wednesday, August 14, 2019 12:12 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3
alpha builds of Resource Monitor and StationPlaylist are now available

OK one query. I've updated nothing on the alpha branch since yesterday, but
booting up alpha today gives...
initializing updateCheck
INFO - core.main (20:07:28.700):
NVDA initialized
DEBUG - core.main (20:07:28.701):
entering wx application main loop
INFO - updateCheck.AutoUpdateChecker._started (20:07:28.712):
Performing automatic update check
IO - speech.speak (20:07:28.739):
Speaking [LangChangeCommand ('en_GB'), 'Taskbar'] DEBUGWARNING -
characterProcessing._getSpeechSymbolsForLocale
(20:07:28.740):
No CLDR data for locale en_GB
ERROR - stderr (20:07:29.565):
Exception in thread Thread-23:
Traceback (most recent call last):
File "threading.pyc", line 926, in _bootstrap_inner
File "threading.pyc", line 870, in run
File "C:\nvda
extra\userConfig\addons\addonUpdater\globalPlugins\addonUpdater\addonHandler
Ex.py",
line 134, in fetchAddonInfo
addonUrl = results[addonKey]
KeyError: 'tbx-stable'
DEBUG - windowUtils.getWindowScalingFactor (20:07:30.091):
GetDpiForWindow failed, using GetDeviceCaps instead IO -
inputCore.InputManager.executeGesture (20:07:33.454):
Input: kb(desktop):downArrow
IO - inputCore.InputManager.executeGesture (20:07:33.998):
Input: kb(desktop):upArrow
IO - inputCore.InputManager.executeGesture (20:07:36.174):
Input: kb(desktop):downArrow
IO - inputCore.InputManager.executeGesture (20:07:37.054):
Input: kb(desktop):alt+tab
IO - speech.speak (20:07:37.117):
Speaking [LangChangeCommand ('en_GB'), '2nvda develop list - Outlook Express
- Brians lists account BGlists icon 1 of 2'] IO - speech.speak
(20:07:37.742):
Speaking [LangChangeCommand ('en_GB'), '2nvda develop list - Outlook Express
- Brians lists account BGlists'] IO - speech.speak (20:07:37.842):
Speaking [LangChangeCommand ('en_GB'), 'Outlook Express Message List list']
IO - speech.speak (20:07:37.940):
Speaking [LangChangeCommand ('en_GB'), "From: Joseph Lee; Subject:
[nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of
Resource Monitor and StationPlaylist are now available; Received: 14/08/2019
18:23 1392 of

Is this due to the way you are stopping Python 3 add ons in add on updater?


Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Wednesday, August 14, 2019 6:23 PM
Subject: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha
builds of Resource Monitor and StationPlaylist are now available


Hi all,



A few days ago I wrote that I'll release Python 3 alpha versions of
some of my add-ons (ones with Python 3 strict branch or requiring NVDA
2019.3
technologies) shortly after NVDA 2019.2 sees the light of day. Now
that it did, I'm releasing Python 3 alpha versions of the following
add-ons:



* Resource Monitor:
http://www.josephsl.net/files/nvdaaddons/py3/resourceMonitor-20190814-
py3.nv
da-addon
* StationPlaylist:
http://www.josephsl.net/files/nvdaaddons/py3/stationPlaylist-20190814-
py3.nv
da-addon





IMPORTANT NOTES:

1. These add-ons REQUIRE NVDA 2019.3 alpha.
2. Update check for these add-ons will not be possible - Add-on
Updater doesn't know how to check for updates for Python 3 alpha
builds, and that is intentional.
3. After installing these add-ons, there is no going back. For this
reason, please use another copy of NVDA for testing these add-ons.
4. For StationPlaylist users: the Python 3 alpha builds of this add-on
will be released only if significant changes were made to SPL add-on
that warrants testing with NVDA 2019.3 alpha. Those on development
snapshots (regular ones, that is) will not see Python 3 version of SPL
add-on until shortly after 2019.3 RC is released; a limited field
testing will take place during 2019.3 beta cycle. Due to pickle
protocol changes, after installing today's alpha snapshot, there is no
going back.
5. For Resource Monitor users: you'll notice smaller download size due
to removal of Python 2 version of psutil. Python 3 alpha version of
Resource Monitor will bundle Python 3 version of psutil.
6. There will be more add-ons joining the Python 3 alpha testing
program, either because they will be optimized for Python 3 (such as
SystrayList), supports newer versions of NVDA (such as Windows 10 App
Essentials), or a combination of these.



Any feedback on my add-ons participating in Python 3 alpha testing are
welcome.

Cheers,

Joseph