Date   
Errors in alpha when using Outlook 365

Andy B.
 

Hi,

 

I get the following errors when opening Outlook 365.

 

ERROR - RPC process 3724 (nvda_slave.exe) (07:21:40.151):

__main__.main:

slave error

Traceback (most recent call last):

  File "nvda_slave.pyw", line 91, in main

  File "comHelper.pyc", line 22, in _lresultFromGetActiveObject

  File "comtypes\client\__init__.pyc", line 180, in GetActiveObject

  File "comtypes\__init__.pyc", line 1245, in GetActiveObject

  File "_ctypes/callproc.c", line 933, in GetResult

OSError: [WinError -2147221021] Operation unavailable

 

 

Re: Add-on Updater 19.08 released, first of two mandatory updates for everyone #addonrelease

Brian's Mail list account
 

Hi this add on when in Alpha and I launch alpha after closing the stable version of nvda has this worning sound.

DEBUG - core.main (13:30:51.371):
Initializing core pump
DEBUG - core.main (13:30:51.371):
Initializing watchdog
DEBUG - core.main (13:30:51.372):
initializing updateCheck
INFO - core.main (13:30:51.375):
NVDA initialized
DEBUG - core.main (13:30:51.375):
entering wx application main loop
IO - speech.speak (13:30:51.408):
Speaking [LangChangeCommand ('en_GB'), 'Taskbar']
DEBUGWARNING - characterProcessing._getSpeechSymbolsForLocale (13:30:51.408):
No CLDR data for locale en_GB
ERROR - stderr (13:30:52.446):
Exception in thread Thread-24:
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'
IO - inputCore.InputManager.executeGesture (13:30:58.320):
Input: kb(desktop):control+alt+r
IO - speech.speak (13:30:58.414):
Speaking [LangChangeCommand ('en_GB'), 'reboot nvda with log terminal']
IO - speech.speak (13:30:58.417):
Speaking [LangChangeCommand ('en_GB'), '80 space', 'blank']
INFO - core.main (13:30:58.505):
Exiting


No idea what it means though.
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 07, 2019 4:43 PM
Subject: [nvda-devel] Add-on Updater 19.08 released, first of two mandatory updates for everyone #AddonRelease


Hi everyone,



Add-on Updater 19.08 is now available. This is the first of two mandatory
updates for anyone using Add-on Updater.



Specifically:



* Version 19.08 removes an experimental feature to present a toast
message on Windows 10 when new add-on updates become available. Although
this is useful, it was found that it isn't ready for primetime yet (thanks
for community feedback). Because this experiment was controlled by a
setting, version 19.08 removes this, hence this being a mandatory update.
* Version 19.08 includes a possible fix for download time-out.
Specifically, if you respond to update notification more than five minutes
of it appearing, you may get an error in regards to update download. This
has been corrected, along with a new way of accessing the add-ons website to
retrieve update status information for various add-ons.



The following describes Add-on Updater releases for the next few weeks:



* 19.08 (released today): supports NVDA 2019.1, first mandatory
update.
* 19.08.1: to be released shortly after NVDA 2019.2 is released. The
only change will be minimum NVDA version supported - 2019.2. This is not a
mandatory update.
* 19.09 (anniversary update): to be released later in August (or by
early September at the latest), second mandatory update for everyone and
requiring NVDA 2019.2 or later. By then, if the time-out bug is resolved,
it'll become a permanent feature of this add-on.



Cheers,

Joseph



Re: Add-on Updater 19.08 released, first of two mandatory updates for everyone #addonrelease

 

Hi,
This means the author may have (and did) provide wrong update channel
identification for stable releases (it should be None, but some add-ons did
say "stable"). I'm going to add a workaround for this issue in 19.08.1 and
19.09 and no more after that.
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: Saturday, August 10, 2019 5:36 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater 19.08 released, first of two
mandatory updates for everyone #AddonRelease

Hi this add on when in Alpha and I launch alpha after closing the stable
version of nvda has this worning sound.

DEBUG - core.main (13:30:51.371):
Initializing core pump
DEBUG - core.main (13:30:51.371):
Initializing watchdog
DEBUG - core.main (13:30:51.372):
initializing updateCheck
INFO - core.main (13:30:51.375):
NVDA initialized
DEBUG - core.main (13:30:51.375):
entering wx application main loop
IO - speech.speak (13:30:51.408):
Speaking [LangChangeCommand ('en_GB'), 'Taskbar'] DEBUGWARNING -
characterProcessing._getSpeechSymbolsForLocale
(13:30:51.408):
No CLDR data for locale en_GB
ERROR - stderr (13:30:52.446):
Exception in thread Thread-24:
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'
IO - inputCore.InputManager.executeGesture (13:30:58.320):
Input: kb(desktop):control+alt+r
IO - speech.speak (13:30:58.414):
Speaking [LangChangeCommand ('en_GB'), 'reboot nvda with log terminal'] IO
- speech.speak (13:30:58.417):
Speaking [LangChangeCommand ('en_GB'), '80 space', 'blank'] INFO - core.main
(13:30:58.505):
Exiting


No idea what it means though.
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 07, 2019 4:43 PM
Subject: [nvda-devel] Add-on Updater 19.08 released, first of two mandatory
updates for everyone #AddonRelease


Hi everyone,



Add-on Updater 19.08 is now available. This is the first of two
mandatory updates for anyone using Add-on Updater.



Specifically:



* Version 19.08 removes an experimental feature to present a toast
message on Windows 10 when new add-on updates become available.
Although this is useful, it was found that it isn't ready for
primetime yet (thanks for community feedback). Because this experiment
was controlled by a setting, version 19.08 removes this, hence this being
a mandatory update.
* Version 19.08 includes a possible fix for download time-out.
Specifically, if you respond to update notification more than five
minutes of it appearing, you may get an error in regards to update
download. This has been corrected, along with a new way of accessing
the add-ons website to retrieve update status information for various
add-ons.



The following describes Add-on Updater releases for the next few weeks:



* 19.08 (released today): supports NVDA 2019.1, first mandatory
update.
* 19.08.1: to be released shortly after NVDA 2019.2 is released. The
only change will be minimum NVDA version supported - 2019.2. This is
not a mandatory update.
* 19.09 (anniversary update): to be released later in August (or by
early September at the latest), second mandatory update for everyone
and requiring NVDA 2019.2 or later. By then, if the time-out bug is
resolved, it'll become a permanent feature of this add-on.



Cheers,

Joseph




Re: Add-on Updater 19.08 released, first of two mandatory updates for everyone #addonrelease

Brian's Mail list account
 

So then that means an add on is set incorrectly does it?
I see None is in most of the ones I've looked at.
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: Saturday, August 10, 2019 2:25 PM
Subject: Re: [nvda-devel] Add-on Updater 19.08 released, first of two mandatory updates for everyone #AddonRelease


Hi,
This means the author may have (and did) provide wrong update channel
identification for stable releases (it should be None, but some add-ons did
say "stable"). I'm going to add a workaround for this issue in 19.08.1 and
19.09 and no more after that.
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: Saturday, August 10, 2019 5:36 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater 19.08 released, first of two
mandatory updates for everyone #AddonRelease

Hi this add on when in Alpha and I launch alpha after closing the stable
version of nvda has this worning sound.

DEBUG - core.main (13:30:51.371):
Initializing core pump
DEBUG - core.main (13:30:51.371):
Initializing watchdog
DEBUG - core.main (13:30:51.372):
initializing updateCheck
INFO - core.main (13:30:51.375):
NVDA initialized
DEBUG - core.main (13:30:51.375):
entering wx application main loop
IO - speech.speak (13:30:51.408):
Speaking [LangChangeCommand ('en_GB'), 'Taskbar'] DEBUGWARNING -
characterProcessing._getSpeechSymbolsForLocale
(13:30:51.408):
No CLDR data for locale en_GB
ERROR - stderr (13:30:52.446):
Exception in thread Thread-24:
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'
IO - inputCore.InputManager.executeGesture (13:30:58.320):
Input: kb(desktop):control+alt+r
IO - speech.speak (13:30:58.414):
Speaking [LangChangeCommand ('en_GB'), 'reboot nvda with log terminal'] IO
- speech.speak (13:30:58.417):
Speaking [LangChangeCommand ('en_GB'), '80 space', 'blank'] INFO - core.main
(13:30:58.505):
Exiting


No idea what it means though.
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 07, 2019 4:43 PM
Subject: [nvda-devel] Add-on Updater 19.08 released, first of two mandatory
updates for everyone #AddonRelease


Hi everyone,



Add-on Updater 19.08 is now available. This is the first of two
mandatory updates for anyone using Add-on Updater.



Specifically:



* Version 19.08 removes an experimental feature to present a toast
message on Windows 10 when new add-on updates become available.
Although this is useful, it was found that it isn't ready for
primetime yet (thanks for community feedback). Because this experiment
was controlled by a setting, version 19.08 removes this, hence this being
a mandatory update.
* Version 19.08 includes a possible fix for download time-out.
Specifically, if you respond to update notification more than five
minutes of it appearing, you may get an error in regards to update
download. This has been corrected, along with a new way of accessing
the add-ons website to retrieve update status information for various
add-ons.



The following describes Add-on Updater releases for the next few weeks:



* 19.08 (released today): supports NVDA 2019.1, first mandatory
update.
* 19.08.1: to be released shortly after NVDA 2019.2 is released. The
only change will be minimum NVDA version supported - 2019.2. This is
not a mandatory update.
* 19.09 (anniversary update): to be released later in August (or by
early September at the latest), second mandatory update for everyone
and requiring NVDA 2019.2 or later. By then, if the time-out bug is
resolved, it'll become a permanent feature of this add-on.



Cheers,

Joseph









Enhanced Touch Gestures August 10th snapshot, a prototype of a future NVDA pull request

 

Hi all,

 

Enhanced Touch Gestures August 10th development snapshot is now available. Note that this build is a prototype for a pull request for NVDA that will be submitted in the future. I’ll make this version available for stable channel subscribers via version 19.09 so more people can try it out before the pull request goes up.

 

To obtain the development snapshot, either go to community add-ons website, go to Enhanced Touch Gestures, and select “development version” link. Alternatively, if you are using Add-on Updater, go to NVDA menu/Preferences/Settings/Add-on Updater and check “Enhanced Touch Gestures” under development releases list (speaking of Add-on Updater and update channels, I’ll write an important reminder about that for add-on authors next week).

 

Changelog:

 

  • Completely disable touch support: now available everywhere. Previously you could not turn this off if using normal profile, meaning NVDA enabled touch support when it starts. This restriction is gone – you can now disable touch support completely even when NVDA starts. If this happens, a beep will indicate the fact that touch support is disabled. This is useful in an environment where you need to use an installed copy of NVDA while someone is helping you via touchscreen input.
  • Configuration flag changes: due to the above change, the former “no touch support” flag no longer applies. If you have previously configured disabling touch support in specific apps (via app-specific profiles), you need to configure them again.

 

Some more things about this add-on:

 

  • Enhanced Touch Gestures is Python 3 compatible. I will solidify this later this year, likely as early as 19.09.
  • A version of this add-on scheduled for later this year will drop support for NVDA releases earlier than 2019 series. Whether this coincides with release of NVDA 2019.3 stable will be determined then, but I’ll give you a grace period (at least a week or so) before dropping support for old NVDA releases.
  • As I noted above, a stable version of today’s snapshot will be made available via version 19.09 (in a few weeks) so stable channel subscribers can meet the redesigned add-on.

Cheers,

Joseph

Re: Add-on Updater 19.08 released, first of two mandatory updates for everyone #addonrelease

 

Hi,
In a way, yes. The ideal channel for stable releases is None (nothing)
because of the way add-ons are listed on community add-ons website (the web
server, that is). This may change once my work comes to NVDA Core (later, as
there are more important things to take care of).
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: Saturday, August 10, 2019 9:02 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater 19.08 released, first of two
mandatory updates for everyone #AddonRelease

So then that means an add on is set incorrectly does it?
I see None is in most of the ones I've looked at.
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: Saturday, August 10, 2019 2:25 PM
Subject: Re: [nvda-devel] Add-on Updater 19.08 released, first of two
mandatory updates for everyone #AddonRelease


Hi,
This means the author may have (and did) provide wrong update channel
identification for stable releases (it should be None, but some
add-ons did say "stable"). I'm going to add a workaround for this
issue in 19.08.1 and
19.09 and no more after that.
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: Saturday, August 10, 2019 5:36 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater 19.08 released, first of two
mandatory updates for everyone #AddonRelease

Hi this add on when in Alpha and I launch alpha after closing the
stable version of nvda has this worning sound.

DEBUG - core.main (13:30:51.371):
Initializing core pump
DEBUG - core.main (13:30:51.371):
Initializing watchdog
DEBUG - core.main (13:30:51.372):
initializing updateCheck
INFO - core.main (13:30:51.375):
NVDA initialized
DEBUG - core.main (13:30:51.375):
entering wx application main loop
IO - speech.speak (13:30:51.408):
Speaking [LangChangeCommand ('en_GB'), 'Taskbar'] DEBUGWARNING -
characterProcessing._getSpeechSymbolsForLocale
(13:30:51.408):
No CLDR data for locale en_GB
ERROR - stderr (13:30:52.446):
Exception in thread Thread-24:
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\addonH
andler
Ex.py",
line 134, in fetchAddonInfo
addonUrl = results[addonKey]
KeyError: 'tbx-stable'
IO - inputCore.InputManager.executeGesture (13:30:58.320):
Input: kb(desktop):control+alt+r
IO - speech.speak (13:30:58.414):
Speaking [LangChangeCommand ('en_GB'), 'reboot nvda with log
terminal'] IO
- speech.speak (13:30:58.417):
Speaking [LangChangeCommand ('en_GB'), '80 space', 'blank'] INFO -
core.main
(13:30:58.505):
Exiting


No idea what it means though.
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 07, 2019 4:43 PM
Subject: [nvda-devel] Add-on Updater 19.08 released, first of two
mandatory updates for everyone #AddonRelease


Hi everyone,



Add-on Updater 19.08 is now available. This is the first of two
mandatory updates for anyone using Add-on Updater.



Specifically:



* Version 19.08 removes an experimental feature to present a toast
message on Windows 10 when new add-on updates become available.
Although this is useful, it was found that it isn't ready for
primetime yet (thanks for community feedback). Because this experiment
was controlled by a setting, version 19.08 removes this, hence this being
a mandatory update.
* Version 19.08 includes a possible fix for download time-out.
Specifically, if you respond to update notification more than five
minutes of it appearing, you may get an error in regards to update
download. This has been corrected, along with a new way of accessing
the add-ons website to retrieve update status information for various
add-ons.



The following describes Add-on Updater releases for the next few weeks:



* 19.08 (released today): supports NVDA 2019.1, first mandatory
update.
* 19.08.1: to be released shortly after NVDA 2019.2 is released. The
only change will be minimum NVDA version supported - 2019.2. This is
not a mandatory update.
* 19.09 (anniversary update): to be released later in August (or by
early September at the latest), second mandatory update for everyone
and requiring NVDA 2019.2 or later. By then, if the time-out bug is
resolved, it'll become a permanent feature of this add-on.



Cheers,

Joseph










Re: Add-on Updater 19.08 released, first of two mandatory updates for everyone #addonrelease

Luke Davis
 

On Sat, 10 Aug 2019, Joseph Lee wrote:

This means the author may have (and did) provide wrong update channel
identification for stable releases (it should be None, but some add-ons did
say "stable").
Could that possibly be because of the following ambiguous statement in the addonTemplate buildVars.py?:

# Add-on update channel (default is stable or None)
"addon_updateChannel" : None,

That does not make clear in the least, that stable and None are the same thing.
It could mean that there are two defaults (depending on what, who knows).
Or it could mean that stable (actually "stable") and None are equivalent.
Or it could mean that there are three options: stable, None, and the implied development/dev, whatever the proper string is for that, without explaining what the None channel is or will do.
Personally I took it to mean the third option, and so released in the "stable" channel.

Can we do this with constants?

STABLE = None
DEV = "development" # or whatever it's supposed to be

Then alter the section in buildVars to say something like:

# Add-on update channel. Set to one of the constants: STABLE or DEV
"addon_updateChannel" : STABLE,

Luke

On Sat, 10 Aug 2019, Joseph Lee wrote:

Hi,
This means the author may have (and did) provide wrong update channel
identification for stable releases (it should be None, but some add-ons did
say "stable"). I'm going to add a workaround for this issue in 19.08.1 and
19.09 and no more after that.
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: Saturday, August 10, 2019 5:36 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater 19.08 released, first of two
mandatory updates for everyone #AddonRelease

Hi this add on when in Alpha and I launch alpha after closing the stable
version of nvda has this worning sound.

DEBUG - core.main (13:30:51.371):
Initializing core pump
DEBUG - core.main (13:30:51.371):
Initializing watchdog
DEBUG - core.main (13:30:51.372):
initializing updateCheck
INFO - core.main (13:30:51.375):
NVDA initialized
DEBUG - core.main (13:30:51.375):
entering wx application main loop
IO - speech.speak (13:30:51.408):
Speaking [LangChangeCommand ('en_GB'), 'Taskbar'] DEBUGWARNING -
characterProcessing._getSpeechSymbolsForLocale
(13:30:51.408):
No CLDR data for locale en_GB
ERROR - stderr (13:30:52.446):
Exception in thread Thread-24:
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'
IO - inputCore.InputManager.executeGesture (13:30:58.320):
Input: kb(desktop):control+alt+r
IO - speech.speak (13:30:58.414):
Speaking [LangChangeCommand ('en_GB'), 'reboot nvda with log terminal'] IO
- speech.speak (13:30:58.417):
Speaking [LangChangeCommand ('en_GB'), '80 space', 'blank'] INFO - core.main
(13:30:58.505):
Exiting


No idea what it means though.
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 07, 2019 4:43 PM
Subject: [nvda-devel] Add-on Updater 19.08 released, first of two mandatory
updates for everyone #AddonRelease


Hi everyone,



Add-on Updater 19.08 is now available. This is the first of two
mandatory updates for anyone using Add-on Updater.



Specifically:



* Version 19.08 removes an experimental feature to present a toast
message on Windows 10 when new add-on updates become available.
Although this is useful, it was found that it isn't ready for
primetime yet (thanks for community feedback). Because this experiment
was controlled by a setting, version 19.08 removes this, hence this being
a mandatory update.
* Version 19.08 includes a possible fix for download time-out.
Specifically, if you respond to update notification more than five
minutes of it appearing, you may get an error in regards to update
download. This has been corrected, along with a new way of accessing
the add-ons website to retrieve update status information for various
add-ons.



The following describes Add-on Updater releases for the next few weeks:



* 19.08 (released today): supports NVDA 2019.1, first mandatory
update.
* 19.08.1: to be released shortly after NVDA 2019.2 is released. The
only change will be minimum NVDA version supported - 2019.2. This is
not a mandatory update.
* 19.09 (anniversary update): to be released later in August (or by
early September at the latest), second mandatory update for everyone
and requiring NVDA 2019.2 or later. By then, if the time-out bug is
resolved, it'll become a permanent feature of this add-on.



Cheers,

Joseph










Re: Add-on Updater 19.08 released, first of two mandatory updates for everyone #addonrelease

 

Hi,
I think a better way to phrase this might be that "None" should be the
default unless noted otherwise by the author. In my case, None is default
(NULL) for stable releases, but there are branches that needs constant
updating that are given their own identification strings (StationPlaylist is
a good example, in that the LTS versions have their own update channel
strings defined).
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Luke Davis
Sent: Saturday, August 10, 2019 11:52 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater 19.08 released, first of two
mandatory updates for everyone #AddonRelease

On Sat, 10 Aug 2019, Joseph Lee wrote:

This means the author may have (and did) provide wrong update channel
identification for stable releases (it should be None, but some
add-ons did say "stable").
Could that possibly be because of the following ambiguous statement in the
addonTemplate buildVars.py?:

# Add-on update channel (default is stable or None) "addon_updateChannel" :
None,

That does not make clear in the least, that stable and None are the same
thing.
It could mean that there are two defaults (depending on what, who knows).
Or it could mean that stable (actually "stable") and None are equivalent.
Or it could mean that there are three options: stable, None, and the implied
development/dev, whatever the proper string is for that, without explaining
what the None channel is or will do.
Personally I took it to mean the third option, and so released in the
"stable"
channel.

Can we do this with constants?

STABLE = None
DEV = "development" # or whatever it's supposed to be

Then alter the section in buildVars to say something like:

# Add-on update channel. Set to one of the constants: STABLE or DEV
"addon_updateChannel" : STABLE,

Luke

On Sat, 10 Aug 2019, Joseph Lee wrote:

Hi,
This means the author may have (and did) provide wrong update channel
identification for stable releases (it should be None, but some
add-ons did say "stable"). I'm going to add a workaround for this
issue in 19.08.1 and
19.09 and no more after that.
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: Saturday, August 10, 2019 5:36 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater 19.08 released, first of two
mandatory updates for everyone #AddonRelease

Hi this add on when in Alpha and I launch alpha after closing the
stable version of nvda has this worning sound.

DEBUG - core.main (13:30:51.371):
Initializing core pump
DEBUG - core.main (13:30:51.371):
Initializing watchdog
DEBUG - core.main (13:30:51.372):
initializing updateCheck
INFO - core.main (13:30:51.375):
NVDA initialized
DEBUG - core.main (13:30:51.375):
entering wx application main loop
IO - speech.speak (13:30:51.408):
Speaking [LangChangeCommand ('en_GB'), 'Taskbar'] DEBUGWARNING -
characterProcessing._getSpeechSymbolsForLocale
(13:30:51.408):
No CLDR data for locale en_GB
ERROR - stderr (13:30:52.446):
Exception in thread Thread-24:
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\addonH
andler
Ex.py",
line 134, in fetchAddonInfo
addonUrl = results[addonKey]
KeyError: 'tbx-stable'
IO - inputCore.InputManager.executeGesture (13:30:58.320):
Input: kb(desktop):control+alt+r
IO - speech.speak (13:30:58.414):
Speaking [LangChangeCommand ('en_GB'), 'reboot nvda with log
terminal'] IO
- speech.speak (13:30:58.417):
Speaking [LangChangeCommand ('en_GB'), '80 space', 'blank'] INFO -
core.main
(13:30:58.505):
Exiting


No idea what it means though.
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 07, 2019 4:43 PM
Subject: [nvda-devel] Add-on Updater 19.08 released, first of two
mandatory updates for everyone #AddonRelease


Hi everyone,



Add-on Updater 19.08 is now available. This is the first of two
mandatory updates for anyone using Add-on Updater.



Specifically:



* Version 19.08 removes an experimental feature to present a toast
message on Windows 10 when new add-on updates become available.
Although this is useful, it was found that it isn't ready for
primetime yet (thanks for community feedback). Because this
experiment was controlled by a setting, version 19.08 removes this,
hence this being
a mandatory update.
* Version 19.08 includes a possible fix for download time-out.
Specifically, if you respond to update notification more than five
minutes of it appearing, you may get an error in regards to update
download. This has been corrected, along with a new way of accessing
the add-ons website to retrieve update status information for various
add-ons.



The following describes Add-on Updater releases for the next few weeks:



* 19.08 (released today): supports NVDA 2019.1, first mandatory
update.
* 19.08.1: to be released shortly after NVDA 2019.2 is released. The
only change will be minimum NVDA version supported - 2019.2. This is
not a mandatory update.
* 19.09 (anniversary update): to be released later in August (or by
early September at the latest), second mandatory update for everyone
and requiring NVDA 2019.2 or later. By then, if the time-out bug is
resolved, it'll become a permanent feature of this add-on.



Cheers,

Joseph











Re: Add-on Updater 19.08 released, first of two mandatory updates for everyone #addonrelease

Luke Davis
 

I wrote:

That does not make clear in the least, that stable and None are the same
That was supposed to say:
That does not make clear in the least, that stable and None aren't the same

Luke

On Sat, 10 Aug 2019, Luke Davis wrote:

On Sat, 10 Aug 2019, Joseph Lee wrote:

This means the author may have (and did) provide wrong update channel
identification for stable releases (it should be None, but some add-ons did
say "stable").
Could that possibly be because of the following ambiguous statement in the addonTemplate buildVars.py?:

# Add-on update channel (default is stable or None)
"addon_updateChannel" : None,

That does not make clear in the least, that stable and None are the same thing.
It could mean that there are two defaults (depending on what, who knows).
Or it could mean that stable (actually "stable") and None are equivalent.
Or it could mean that there are three options: stable, None, and the implied development/dev, whatever the proper string is for that, without explaining what the None channel is or will do.
Personally I took it to mean the third option, and so released in the "stable" channel.

Can we do this with constants?

STABLE = None
DEV = "development" # or whatever it's supposed to be

Then alter the section in buildVars to say something like:

# Add-on update channel. Set to one of the constants: STABLE or DEV
"addon_updateChannel" : STABLE,

Luke

On Sat, 10 Aug 2019, Joseph Lee wrote:

Hi,
This means the author may have (and did) provide wrong update channel
identification for stable releases (it should be None, but some add-ons did
say "stable"). I'm going to add a workaround for this issue in 19.08.1 and
19.09 and no more after that.
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: Saturday, August 10, 2019 5:36 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater 19.08 released, first of two
mandatory updates for everyone #AddonRelease
Hi this add on when in Alpha and I launch alpha after closing the stable
version of nvda has this worning sound.
DEBUG - core.main (13:30:51.371):
Initializing core pump
DEBUG - core.main (13:30:51.371):
Initializing watchdog
DEBUG - core.main (13:30:51.372):
initializing updateCheck
INFO - core.main (13:30:51.375):
NVDA initialized
DEBUG - core.main (13:30:51.375):
entering wx application main loop
IO - speech.speak (13:30:51.408):
Speaking [LangChangeCommand ('en_GB'), 'Taskbar'] DEBUGWARNING -
characterProcessing._getSpeechSymbolsForLocale
(13:30:51.408):
No CLDR data for locale en_GB
ERROR - stderr (13:30:52.446):
Exception in thread Thread-24:
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'
IO - inputCore.InputManager.executeGesture (13:30:58.320):
Input: kb(desktop):control+alt+r
IO - speech.speak (13:30:58.414):
Speaking [LangChangeCommand ('en_GB'), 'reboot nvda with log terminal'] IO
- speech.speak (13:30:58.417):
Speaking [LangChangeCommand ('en_GB'), '80 space', 'blank'] INFO - core.main
(13:30:58.505):
Exiting
No idea what it means though.
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 07, 2019 4:43 PM
Subject: [nvda-devel] Add-on Updater 19.08 released, first of two mandatory
updates for everyone #AddonRelease

Hi everyone,
Add-on Updater 19.08 is now available. This is the first of two
mandatory updates for anyone using Add-on Updater.
Specifically:
* Version 19.08 removes an experimental feature to present a toast
message on Windows 10 when new add-on updates become available.
Although this is useful, it was found that it isn't ready for
primetime yet (thanks for community feedback). Because this experiment
was controlled by a setting, version 19.08 removes this, hence this being
a mandatory update.
* Version 19.08 includes a possible fix for download time-out.
Specifically, if you respond to update notification more than five
minutes of it appearing, you may get an error in regards to update
download. This has been corrected, along with a new way of accessing
the add-ons website to retrieve update status information for various
add-ons.
The following describes Add-on Updater releases for the next few weeks:
* 19.08 (released today): supports NVDA 2019.1, first mandatory
update.
* 19.08.1: to be released shortly after NVDA 2019.2 is released. The
only change will be minimum NVDA version supported - 2019.2. This is
not a mandatory update.
* 19.09 (anniversary update): to be released later in August (or by
early September at the latest), second mandatory update for everyone
and requiring NVDA 2019.2 or later. By then, if the time-out bug is
resolved, it'll become a permanent feature of this add-on.
Cheers,
Joseph

Re: Add-on Updater 19.08 released, first of two mandatory updates for everyone #addonrelease

Luke Davis
 

On Sat, 10 Aug 2019, Joseph Lee wrote:

I think a better way to phrase this might be that "None" should be the
default unless noted otherwise by the author. In my case, None is default
But the author is the one doing the noting in buildVars.py, and so the resulting confusion factor is unchanged.
That still leaves a variable to the discretion of the author, who may have no idea what he should want it to be.

It is nowhere made clear how the channel is used internally by NVDA, or the scripts behind the community add-ons site, or anything else.

Perhaps we should say:

# Add-on update channel: set to None unless you really know what you are doing

Luke

Re: Add-on Updater 19.08 released, first of two mandatory updates for everyone #addonrelease

 

Hi,
Let's see...
Currently, when one looks at add-on files repo and opens up the PHP file
responsible for hosting add-on download keys, you'll notice that add-ons
with stable releases does not have a qualifier after the short add-on name
key. For example, for Toolbars Explorer, the key is tbx, and the stable
version is just labeled "tbx" without any qualifier. This is the key
characteristic that allows Add-on Updater to decide which key to look up,
along with being guided by manifests from add-ons.
The above came about because until last year there was no update channel
defined in manifests for vast majority of add-ons; the first two add-ons
that had channel set were ones that had update check facility built in:
StationPlaylist and Windows 10 App Essentials. Also, in the early days of
community add-ons website, we only had two channels: stable and development,
with the only difference being the qualifier at the end of the add-on
download key (a key with "-dev" indicated a development channel, whereas
just the key meant stable). To account for these, Add-on Updater, which can
be traced to StationPlaylist's update check facility with some things coming
from Windows 10 App Essentials, is programmed to view "None" (nothing) as
stable release, with added bits from Add-on Template's build vars module
based on ones from StationPlaylist.
Part of the reason why update check is failing for some add-ons with
"stable" string set as update channel is precisely because of the ambiguity
mentioned, which will be corrected in the add-on template this weekend with
help from people.
As for viewing None as same as stable (and telling authors to leave the
update channel as "None" for stable releases), that can change depending on
how the server counterpart to Add-on Updater (put on hold due to Python 3
work) is programmed. As of now, Add-on Updater performs the role of a
"client" and a "server": client as far as fetching update info is concerned,
and checking the manifest for channels and parsing version info is the job
of the server component.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Luke Davis
Sent: Saturday, August 10, 2019 12:10 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater 19.08 released, first of two
mandatory updates for everyone #AddonRelease

I wrote:

That does not make clear in the least, that stable and None are the
same
That was supposed to say:
That does not make clear in the least, that stable and None aren't the same

Luke

On Sat, 10 Aug 2019, Luke Davis wrote:

On Sat, 10 Aug 2019, Joseph Lee wrote:

This means the author may have (and did) provide wrong update channel
identification for stable releases (it should be None, but some
add-ons did say "stable").
Could that possibly be because of the following ambiguous statement in
the addonTemplate buildVars.py?:

# Add-on update channel (default is stable or None)
"addon_updateChannel" : None,

That does not make clear in the least, that stable and None are the
same thing.
It could mean that there are two defaults (depending on what, who knows).
Or it could mean that stable (actually "stable") and None are equivalent.
Or it could mean that there are three options: stable, None, and the
implied development/dev, whatever the proper string is for that,
without explaining what the None channel is or will do.
Personally I took it to mean the third option, and so released in the
"stable" channel.

Can we do this with constants?

STABLE = None
DEV = "development" # or whatever it's supposed to be

Then alter the section in buildVars to say something like:

# Add-on update channel. Set to one of the constants: STABLE or DEV
"addon_updateChannel" : STABLE,

Luke

On Sat, 10 Aug 2019, Joseph Lee wrote:

Hi,
This means the author may have (and did) provide wrong update channel
identification for stable releases (it should be None, but some
add-ons did say "stable"). I'm going to add a workaround for this
issue in 19.08.1 and
19.09 and no more after that.
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: Saturday, August 10, 2019 5:36 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater 19.08 released, first of two
mandatory updates for everyone #AddonRelease

Hi this add on when in Alpha and I launch alpha after closing the
stable version of nvda has this worning sound.

DEBUG - core.main (13:30:51.371):
Initializing core pump
DEBUG - core.main (13:30:51.371):
Initializing watchdog
DEBUG - core.main (13:30:51.372):
initializing updateCheck
INFO - core.main (13:30:51.375):
NVDA initialized
DEBUG - core.main (13:30:51.375):
entering wx application main loop
IO - speech.speak (13:30:51.408):
Speaking [LangChangeCommand ('en_GB'), 'Taskbar'] DEBUGWARNING -
characterProcessing._getSpeechSymbolsForLocale
(13:30:51.408):
No CLDR data for locale en_GB
ERROR - stderr (13:30:52.446):
Exception in thread Thread-24:
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\addon
Handler
Ex.py",
line 134, in fetchAddonInfo
addonUrl = results[addonKey]
KeyError: 'tbx-stable'
IO - inputCore.InputManager.executeGesture (13:30:58.320):
Input: kb(desktop):control+alt+r
IO - speech.speak (13:30:58.414):
Speaking [LangChangeCommand ('en_GB'), 'reboot nvda with log
terminal'] IO
- speech.speak (13:30:58.417):
Speaking [LangChangeCommand ('en_GB'), '80 space', 'blank'] INFO -
core.main
(13:30:58.505):
Exiting


No idea what it means though.
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 07, 2019 4:43 PM
Subject: [nvda-devel] Add-on Updater 19.08 released, first of two
mandatory updates for everyone #AddonRelease


Hi everyone,



Add-on Updater 19.08 is now available. This is the first of two
mandatory updates for anyone using Add-on Updater.



Specifically:



* Version 19.08 removes an experimental feature to present a toast
message on Windows 10 when new add-on updates become available.
Although this is useful, it was found that it isn't ready for
primetime yet (thanks for community feedback). Because this
experiment was controlled by a setting, version 19.08 removes this,
hence this being
a mandatory update.
* Version 19.08 includes a possible fix for download time-out.
Specifically, if you respond to update notification more than five
minutes of it appearing, you may get an error in regards to update
download. This has been corrected, along with a new way of accessing
the add-ons website to retrieve update status information for
various add-ons.



The following describes Add-on Updater releases for the next few weeks:



* 19.08 (released today): supports NVDA 2019.1, first mandatory
update.
* 19.08.1: to be released shortly after NVDA 2019.2 is released. The
only change will be minimum NVDA version supported - 2019.2. This is
not a mandatory update.
* 19.09 (anniversary update): to be released later in August (or by
early September at the latest), second mandatory update for everyone
and requiring NVDA 2019.2 or later. By then, if the time-out bug is
resolved, it'll become a permanent feature of this add-on.



Cheers,

Joseph













Re: Add-on Updater 19.08 released, first of two mandatory updates for everyone #addonrelease

 

Hi,
As for explanation as to how update channel is calculated, see another
message sent a few minutes ago.
As for the key description, I think the suggested wording sounds fine, with
a caveat that there should be an explanation (within brackets) that
clarifies what "None" means if left alone.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Luke Davis
Sent: Saturday, August 10, 2019 12:19 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater 19.08 released, first of two
mandatory updates for everyone #AddonRelease

On Sat, 10 Aug 2019, Joseph Lee wrote:

I think a better way to phrase this might be that "None" should be the
default unless noted otherwise by the author. In my case, None is
default
But the author is the one doing the noting in buildVars.py, and so the
resulting confusion factor is unchanged.
That still leaves a variable to the discretion of the author, who may have
no idea what he should want it to be.

It is nowhere made clear how the channel is used internally by NVDA, or the
scripts behind the community add-ons site, or anything else.

Perhaps we should say:

# Add-on update channel: set to None unless you really know what you are
doing

Luke

Re: Add-on Updater 19.08 released, first of two mandatory updates for everyone #addonrelease

Luke Davis
 

On Sat, 10 Aug 2019, Joseph Lee wrote:

As for explanation as to how update channel is calculated, see another
message sent a few minutes ago.
Yes, and interesting it is. Sadly, the new add-on developer reading existing documentation will have no way of knowing any of it. It is part of institutional deep knowledge--things that are just "known" by people who have been inside for a long while, or intentionally set out to learn it.

As I have discussed with you privately, my goal is to make the add-on development process as un-obscure as possible, with as little documentation and knowledge scatter as we can manage. Which is why I'm harping on this.:)

> As for the key description, I think the suggested wording sounds fine, with
a caveat that there should be an explanation (within brackets) that
clarifies what "None" means if left alone.
Quite right. Perhaps this?

# Add-on update channel: should be None (for stable add-ons), or "dev" (with quotes)
# (for development releases). You can create your own custom channels if you really know what you're doing.

Luke

Re: Add-on Updater 19.08 released, first of two mandatory updates for everyone #addonrelease

 

Hi,
Description: yes, I think that should work (I'll commit the changes to
template repo on Monday provided that others are in agreement).
Channel process and explanations: we do need to document this - I've been
meaning to write an add-on internals document for Add-on Updater that
describes how channels are identified and other internals. This internals
document will be modeled on StationPlaylist add-on internals document, which
can be found here:
https://github.com/josephsl/stationplaylist/wiki/spladdoninternals
For this thread, the section on "update check" should serve as foundation
for the document.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Luke Davis
Sent: Saturday, August 10, 2019 12:45 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater 19.08 released, first of two
mandatory updates for everyone #AddonRelease

On Sat, 10 Aug 2019, Joseph Lee wrote:

As for explanation as to how update channel is calculated, see another
message sent a few minutes ago.
Yes, and interesting it is. Sadly, the new add-on developer reading existing
documentation will have no way of knowing any of it. It is part of
institutional deep knowledge--things that are just "known" by people who
have been inside for a long while, or intentionally set out to learn it.

As I have discussed with you privately, my goal is to make the add-on
development process as un-obscure as possible, with as little documentation
and knowledge scatter as we can manage. Which is why I'm harping on this.:)

> As for the key description, I think the suggested wording sounds fine,
with
a caveat that there should be an explanation (within brackets) that
clarifies what "None" means if left alone.
Quite right. Perhaps this?

# Add-on update channel: should be None (for stable add-ons), or "dev" (with
quotes) # (for development releases). You can create your own custom
channels if you really know what you're doing.

Luke

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: [nvda-addons] Add-on template and update channel definition: updates, a word about update channel definition

Luke Davis
 

Thanks for this work Joseph, and for so swiftly resolving the situation. Also thanks for expounding the history further.

Luke

Control Usage Assistant: coming back to life, version 2.5/nightlight version is on its way #addonrelease

 

Hi everyone,

 

For users of Control Usage Assistant: reports of its demise has greatly been exaggerated…

 

I’m delighted to announce that Control Usage Assistant is being resurrected i.e. supported again. This add-on added a command (NVDA+H) that gives you a handy help message for working with the focused control, similar to help messages from other screen readers.

 

Originally, Derek Riemer, a member of the NVDA community, was planning to maintain this add-on. After a short Twitter conversation, it was decided that I’ll maintain it after all. Thus, the “end of life” (EOL) tag is gone.

 

Speaking of resurrecting this add-on several big announcements:

 

  • Version 2.5/nightlight: as promised a few days ago, version 2.5 of Control Usage Assistant, or version nightlight, will be made available in the next hour or so. This one is huge in that it introduces a rewritten readme and makes the add-on Python 3 ready.
  • New add-on source code repository: with the add-on coming back to life, I figured it is time to give it a new home. For anyone wishing to look at source code for this add-on can now do so by going to t. Consequently, the next big update after version 2.5/nightlight will be downloadable from GitHub.
  • Speaking of a big update: yes, it is coming (likely later this year). Tentatively known as Control usage Assistant generation 3 (or NG/next generation), this version will not only change the versioning scheme to match the rest of my add-ons (year.month.revision), it’ll bring a completely new way of reviewing help information. Previously when you pressed NVDA+H, help messages were spoken and/or brailled on the spot. Starting with the next update, it’ll become a browse mode window, mirroring help message screens from other screen readers.

 

Other key features of the big update:

 

  • Add-on name: to be shortened to just “Control Usage Assistant”.
  • More contextual: not only the help message based on the type of the control will be shown, a more comprehensive and contextual help message will be provided. This may include not only working with specific types of controls, it may include help coming from other add-ons, app help messages, and perhaps more. In other words, the way the help message is obtained will be reborn from scratch.
  • Extensible (perhaps coming later): authors of add-ons will be able to supplement help messages for specific controls and/or apps. For example, an author of an app module can ask Control Usage Assistant to present a specific help message for an overlay control seen in an app.
  • Requires NVDA 2019 series, most likely upcoming 2019.3 (later this year).

 

For those keeping an eye on GitHub issues: for a number of years you may have seen a request for context-sensitive help for NVDA. The issue in question is 2699 and can be found at:

https://github.com/nvaccess/nvda/issues/2699

 

In fact, development of Control Usage Assistant began shortly after that issue appeared. In other words, what you will see with the next big update is really a prototype for a feature that might be included in a future NVDA release (and yes, I know I start to sound very repetitive, but there is a pull request for this feature somewhere that will look similar to Control Usage Assistant generation 3).

 

I’m sure you’d like to test the next big update. I plan to release a prototype development snapshot of that release in a few weeks, which will require NVDA 2019.1 or later.

 

Tanks.

Cheers,

Joseph

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