Date   
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: 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

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: 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




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: 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

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

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

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: [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

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 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

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,
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

 

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

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

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

 

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
 

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,
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