Add-on Updater: announcing Project Meteor to refactor add-on download and install routines


 

Hi all,

As I hinted earlier, I’m delighted to announce that a major add-on refactoring work is in progress for Add-on Updater. This work, codenamed “Project Meteor”, is designed to separate add-on download and install routines from the accompanying graphical user interface (GUI), similar to the internals of add-on update check facility.

Currently when you check for, download, and install add-ons via Add-on Updater, you will see several progress dialogs. These dialogs communicate the stage Add-on Updater is in such as checking for updates, downloading add-ons, and applying updates. For update check dialog, you won’t see it until you select “check for add-on updates” menu item from NVDA Tools menu, and at other times, you will be greeted with a toast informing you of add-on updates. This is possible because the actual code that checks for add-on updates is independent of the update check progress dialog code. When you do choose to update add-ons, a downloader class is used to both download and install add-ons, with the code relying on the resulting download and install progress dialogs. This downloader is capable of downloading and updating one add-on at a time, and in case of multiple add-on updates, a generator is used to coordinate add-on download and install routines.

The immediate goal of Project Meteor is to apply UI and algorithm separation to add-on download and install routines. The idea is to allow Add-on Updater to apply updates in the background without presenting GUI’s, useful in update automation scenarios. It will also allow the add-on code to be cleaned up and improve readability, a key requirement for add-on maintenance. To coordinate Project Meteor, a new module (addonUpdateProc) will be introduced to house base implementation for add-on update check, download, and install internals.

The secondary goal of Project Meteor is to improve the overall download and install experience. Currently add-ons are downloaded and updated one at a time (add-on 1 download, add-on 1 install, add-on 2 download, add-on 2 install, and so on). With Project Meteor, the routine will change so that all add-on updates will be downloaded at once, followed by install attempt for all add-ons at once (add-on 1 download, add-on 2 download, install all add-ons at once).

There are two changes as a result:

  1. Download and install progress dialogs: instead of showing multiple progress dialogs one after the other (noticeable if you have many add-on updates), only two dialogs will be shown: one dialog for showing progress of all add-on downloads, and a follow-up progress dialog for showing install progress. This means you will not hear progress beeps for individual add-ons, but I’m thinking about ways to give you some form of a progress indicator.
  2. Concurrent downloads and installs: as the actual download and install routines will be separated from progress dialogs, these routines can run concurrently (or close to it) via threads. In some ways, this is implemented in parts of add-on update check routine (threads are employed when checking add-on compatibility and other metadata for all installed add-ons at once, with each thread devoted to checking metadata for an add-on). This cannot be employed in GUI mode but is a useful optimization for automated add-on update feature.

 

As of this post, Project Meteor is slightly ahead of schedule. I can say that actual add-on download and install routines are now separate from GUI code, and I’m finalizing minimal test case specs so you can test it (via Python Console). As soon as test case specs is finalized, I will release an Add-on Updater try build with Project Meteor applied (no GUI changes whatsoever but the new code is present), meant for developers and power users (people who are comfortable with Python Console) to give feedback before introducing GUI changes. Details about Project Meteor can be found here:

Project Meteor: separate add-on update, download, and install functions from the user interface · Issue #11 · josephsl/addonUpdater (github.com)

 

If things go well, Project Meteor will be a big highlight of Add-on Updater 22.08 (which may also turn out to be the final Add-on Updater version to support NVDA 2021.3.x). Automated add-on update facility will not be part of the upcoming Add-on Updater stable release as the immediate task is incorporating your feedback; but if the implementation is mature enough, it could be included in Add-on Updater 22.08.

Thanks.

Cheers,

Joseph


 

Hi all,

Add-on Updater July 2nd Project Meteor try build is now available (read important notes below):

https://github.com/josephsl/addonUpdater/releases/download/22.07/addonUpdater-tryProjectMeteor20220702.nvda-addon

 

IMPORTANT NOTES:

  • This is a try build – it contains latest work in progress. Thus it can cause issues for some. DO NOT USE THIS IN PRODUCTION ENVIRONMENTS!
  • While bulk of Project Meteor is included in this build, there are bugs to be aware of and yet to be discovered.
  • This build is meant for developers and advanced users wishing to provide feedback on Project Meteor. You can obtain the source code for this build by either unpacking the add-on installer package or via Git (https://github.com/josephsl/addonupdater, checkout both “meteor” and “meteortest” branches).

 

Testing Project Meteor:

  1. After installing the try build, open Python Console.
  2. Import globalPlugins package.
  3. Obtain “add-on updates” by calling globalPlugins.addonUpdater.addonUpdateProc.checkForAddonUpdates() function. Alternatively, use a variable to store the dictionary coming from this function. See below for why updates are in quotes.
  4. Test parts of Project Meteor, most notably globalPlugins.addonUpdater.addonUpdateProc.test_downloadAndInstallAddonUpdates function and pass in the updates dictionary obtained earlier. This function simulates automatic add-on download and install feature. If add-ons ask you something during the install process, respond appropriately.
  5. You can test other parts of Project Meteor such as download process (globalPlugins.addonUpdater.addonUpdateProc. downloadAddonUpdate(addonUrl, tempFilePath,hash) (hash should be None for now) and install process (globalPlugins.addonUpdater.addonUpdateProc. installAddonUpdate(tempFilePath, addonSummary). These functions will download and install add-ons respectively, and for the latter, status flag is returned.

 

Bugs and things to be aware of:

  • No exception handling when downloading add-ons (planned): for now add-on download facility does not handle exceptions. I plan to add exception handlers so that add-on install can be skipped or an error dialog is shown if you are testing Project Meteor internals or UI, respectively.
  • No user interface for Project Meteor (planned): user interface is in the works, but the purpose of the try build is to test internals first.
  • Latest add-on updates are downloaded (for testing purposes): internally, NVDA will report currently installed add-on versions as “0.0”. This is done for testing the download and install processes. I plan to restore current versions when Project Meteor code goes through additional testing.
  • Add-on Updater latest version is downloaded after installing this try build (bug): you can resolve this by telling NVDA to not update Add-on Updater while testing Project Meteor.
  • Add-on update check routine is duplicated across modules (for testing purposes): parts of add-on update check routine is duplicated across extended add-on handler and update process modules. Duplicate code will be removed when Project Meteor enters integration testing phase.
  • Add-ons can present installation dialogs (no fix planned): some add-ons present installation messages such as Windows App Essentials. I have no plans to fix this as these messages come from add-ons other than Add-on Updater.
  • Beeps are heard when downloading add-ons but a progress dialog is not shown (intentional): this is a form of progress indicator meant to test add-on download facility.

 

Two more things:

  1. This build is not meant to be used by regular users. I will present a more stable test build to the NVDA user community in the future.
  2. Feedback is welcome – please do reply to this thread or send me a direct message if you have suggestions or comments.

 

Happy testing.

Cheers,

Joseph

 

 

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Joseph Lee via groups.io
Sent: Saturday, July 2, 2022 10:56 AM
To: nvda-addons@nvda-addons.groups.io
Subject: [nvda-addons] Add-on Updater: announcing Project Meteor to refactor add-on download and install routines

 

Hi all,

As I hinted earlier, I’m delighted to announce that a major add-on refactoring work is in progress for Add-on Updater. This work, codenamed “Project Meteor”, is designed to separate add-on download and install routines from the accompanying graphical user interface (GUI), similar to the internals of add-on update check facility.

Currently when you check for, download, and install add-ons via Add-on Updater, you will see several progress dialogs. These dialogs communicate the stage Add-on Updater is in such as checking for updates, downloading add-ons, and applying updates. For update check dialog, you won’t see it until you select “check for add-on updates” menu item from NVDA Tools menu, and at other times, you will be greeted with a toast informing you of add-on updates. This is possible because the actual code that checks for add-on updates is independent of the update check progress dialog code. When you do choose to update add-ons, a downloader class is used to both download and install add-ons, with the code relying on the resulting download and install progress dialogs. This downloader is capable of downloading and updating one add-on at a time, and in case of multiple add-on updates, a generator is used to coordinate add-on download and install routines.

The immediate goal of Project Meteor is to apply UI and algorithm separation to add-on download and install routines. The idea is to allow Add-on Updater to apply updates in the background without presenting GUI’s, useful in update automation scenarios. It will also allow the add-on code to be cleaned up and improve readability, a key requirement for add-on maintenance. To coordinate Project Meteor, a new module (addonUpdateProc) will be introduced to house base implementation for add-on update check, download, and install internals.

The secondary goal of Project Meteor is to improve the overall download and install experience. Currently add-ons are downloaded and updated one at a time (add-on 1 download, add-on 1 install, add-on 2 download, add-on 2 install, and so on). With Project Meteor, the routine will change so that all add-on updates will be downloaded at once, followed by install attempt for all add-ons at once (add-on 1 download, add-on 2 download, install all add-ons at once).

There are two changes as a result:

  1. Download and install progress dialogs: instead of showing multiple progress dialogs one after the other (noticeable if you have many add-on updates), only two dialogs will be shown: one dialog for showing progress of all add-on downloads, and a follow-up progress dialog for showing install progress. This means you will not hear progress beeps for individual add-ons, but I’m thinking about ways to give you some form of a progress indicator.
  2. Concurrent downloads and installs: as the actual download and install routines will be separated from progress dialogs, these routines can run concurrently (or close to it) via threads. In some ways, this is implemented in parts of add-on update check routine (threads are employed when checking add-on compatibility and other metadata for all installed add-ons at once, with each thread devoted to checking metadata for an add-on). This cannot be employed in GUI mode but is a useful optimization for automated add-on update feature.

 

As of this post, Project Meteor is slightly ahead of schedule. I can say that actual add-on download and install routines are now separate from GUI code, and I’m finalizing minimal test case specs so you can test it (via Python Console). As soon as test case specs is finalized, I will release an Add-on Updater try build with Project Meteor applied (no GUI changes whatsoever but the new code is present), meant for developers and power users (people who are comfortable with Python Console) to give feedback before introducing GUI changes. Details about Project Meteor can be found here:

Project Meteor: separate add-on update, download, and install functions from the user interface · Issue #11 · josephsl/addonUpdater (github.com)

 

If things go well, Project Meteor will be a big highlight of Add-on Updater 22.08 (which may also turn out to be the final Add-on Updater version to support NVDA 2021.3.x). Automated add-on update facility will not be part of the upcoming Add-on Updater stable release as the immediate task is incorporating your feedback; but if the implementation is mature enough, it could be included in Add-on Updater 22.08.

Thanks.

Cheers,

Joseph


 
Edited

Hi all,

Add-on Updater Project Meteor July 4th try build is now available (suitable for wider testing, see notes below): https://github.com/josephsl/addonUpdater/releases/download/22.07/addonUpdater-tryProjectMeteor20220704.nvda-addon

Changes from the previous try build:

  • Download error handling: listeners to add-on download routines will now handle runtime errors.
  • Socket error handling: if Internet becomes disconnected while downloading add-ons, NVDA will raise an exception to communicate this fact. This error will also be handled by download routine listeners.
  • Project Meteor UI and tests: you can (finally) test Project Meteor using the graphical user interface. After installing this try build, when you check for add-on updates, NVDA will present a dialog called "Project Meteor add-on update check". This is done for obvious reason: to help people identify that this is work in progress. When you do select add-ons to update, you will then be greeted with the progress dialog that's quite different than what you are used to: a single progress dialog showing update download status. But that's not the biggest change: previously you were used to seeing download and update dialogs one after the other; not anymore: if you are downloading multiple add-ons, download progress will be shown, followed by update dialog once ALL add-ons are downloaded. Don't worry if the dialog text is not what you were expecting - this will be fixed in a future try build. To accompany GUI changes, a new function was added to test the UI portion (globalPlugins.addonUpdater.addonUpdateProc.test_downloadAndInstallAddonUpdatesUI, taking the list of update records, explained below).
  • Add-on update record: a new class (addonUpdateProc.AddonUpdateRecord) is now available to record update metadata such as summary, installed version, update version, update URL, compatibility range, among others. This lays the foundation for further integration testing (currently the UI portion of this try build uses older update dictionary to store update metadata; this will change in a future try build to use update records directly) and other future possibilities (one possibility is "update check protocol" where Add-on Updater could support multiple ways to obtain add-on update metadata, chiefly from multiple sources; this requires refactoring current add-on update check facility).

Things to be aware of:

  • Add-on versions are shown as 0.0 (testing): this is meant to provide compatibility with current update check facility. I plan to allow Add-on Updater to show you the actually installed add-on version in a future try build.
  • Ad-on install errors are not handled (planned): sometimes NVDA may present messages such as compatibility error if the add-on is deemed incompatible. The foundation to handle cases like this is present - the UI for it will be shown in a future try build.
  • Add-on Updater update is offered after installing this try build (no change): to resolve this, just before installing the linked try build, tell NVDA to not offer updates to Add-on Updater. This bug will be resolved once Project Meteor is done and becomes part of a future Add-on Updater stable release.

This try build is of a sufficient quality to be tested by advanced users (a message about Project Meteor will be sent to NVDA users list once I finish translating this entire thread to a form understandable by users). Feedback is appreciated.

Cheers,

Jsoeph


Noelia Ruiz
 

Hello:

I love the notifications presented without a dialog, just Windows
notifications, available to review with Windows+a.
I get the following error:

ERROR - unhandled exception (21:17:54.055) - MainThread (6460):
Traceback (most recent call last):
File "C:\Users\nrm19\AppData\Roaming\nvda\addons\addonUpdater\globalPlugins\addonUpdater\addonGuiEx.py",
line 155, in onUpdate
updateAddonsProjectMeteor(list(self.addonUpdateInfo.values()),
auto=self.auto)
File "C:\Users\nrm19\AppData\Roaming\nvda\addons\addonUpdater\globalPlugins\addonUpdater\addonGuiEx.py",
line 379, in updateAddonsProjectMeteor
name=addon["name"],
KeyError: 'name'
Cheers

2022-07-04 18:02 GMT+02:00, Joseph Lee <joseph.lee22590@...>:

[Edited Message Follows]

Hi all,

Add-on Updater Project Meteor July 4th try build is now available (suitable
for wider testing, see notes below):
https://github.com/josephsl/addonUpdater/releases/download/22.07/addonUpdater-tryProjectMeteor20220704.nvda-addon

Changes from the previous try build:

* Download error handling: listeners to add-on download routines will now
handle runtime errors.
* Socket error handling: if Internet becomes disconnected while downloading
add-ons, NVDA will raise an exception to communicate this fact. This error
will also be handled by download routine listeners.
* Project Meteor UI and tests: you can (finally) test Project Meteor using
the graphical user interface. After installing this try build, when you
check for add-on updates, NVDA will present a dialog called "Project Meteor
add-on update check". This is done for obvious reason: to help people
identify that this is work in progress. When you do select add-ons to
update, you will then be greeted with the progress dialog that's quite
different than what you are used to: a single progress dialog showing update
download status. But that's not the biggest change: previously you were used
to seeing download and update dialogs one after the other; not anymore: if
you are downloading multiple add-ons, download progress will be shown,
followed by update dialog once ALL add-ons are downloaded. Don't worry if
the dialog text is not what you were expecting - this will be fixed in a
future try build. To accompany GUI changes, a new function was added to test
the UI portion
(globalPlugins.addonUpdater.addonUpdateProc.test_downloadAndInstallAddonUpdatesUI,
taking the list of update records, explained below).
* Add-on update record: a new class (addonUpdateProc.AddonUpdateRecord) is
now available to record update metadata such as summary, installed version,
update version, update URL, compatibility range, among others. This lays the
foundation for further integration testing (currently the UI portion of this
try build uses older update dictionary to store update metadata; this will
change in a future try build to use update records directly) and other
future possibilities (one possibility is "update check protocol" where
Add-on Updater could support multiple ways to obtain add-on update metadata,
chiefly from multiple sources; this requires refactoring current add-on
update check facility).

Things to be aware of:

* Add-on versions are shown as 0.0 (testing): this is meant to provide
compatibility with current update check facility. I plan to allow Add-on
Updater to show you the actually installed add-on version in a future try
build.
* Ad-on install errors are not handled (planned): sometimes NVDA may present
messages such as compatibility error if the add-on is deemed incompatible.
The foundation to handle cases like this is present - the UI for it will be
shown in a future try build.
* Add-on Updater update is offered after installing this try build (no
change): to resolve this, just before installing the linked try build, tell
NVDA to not offer updates to Add-on Updater. This bug will be resolved once
Project Meteor is done and becomes part of a future Add-on Updater stable
release.

This try build is of a sufficient quality to be tested by advanced users (a
message about Project Meteor will be sent to NVDA users list once I finish
translating this entire thread to a form understandable by users). Feedback
is appreciated.

Cheers,

Jsoeph






 

Hi,
This is a bug caused by the fact that when Add-on Updater toast appears, the updates metadata dictionary does not contain the "name" key, traced to the fact that the update check routine that ultimately results in toast announcement uses the current update check routine, not Project Meteor approach. I plan o fix this in the next try build (as soon as possible).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Monday, July 4, 2022 12:21 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Add-on Updater: announcing Project Meteor to refactor add-on download and install routines

Hello:

I love the notifications presented without a dialog, just Windows notifications, available to review with Windows+a.
I get the following error:

ERROR - unhandled exception (21:17:54.055) - MainThread (6460):
Traceback (most recent call last):
File "C:\Users\nrm19\AppData\Roaming\nvda\addons\addonUpdater\globalPlugins\addonUpdater\addonGuiEx.py",
line 155, in onUpdate
updateAddonsProjectMeteor(list(self.addonUpdateInfo.values()),
auto=self.auto)
File "C:\Users\nrm19\AppData\Roaming\nvda\addons\addonUpdater\globalPlugins\addonUpdater\addonGuiEx.py",
line 379, in updateAddonsProjectMeteor
name=addon["name"],
KeyError: 'name'
Cheers

2022-07-04 18:02 GMT+02:00, Joseph Lee <joseph.lee22590@...>:
[Edited Message Follows]

Hi all,

Add-on Updater Project Meteor July 4th try build is now available
(suitable for wider testing, see notes below):
https://github.com/josephsl/addonUpdater/releases/download/22.07/addon
Updater-tryProjectMeteor20220704.nvda-addon

Changes from the previous try build:

* Download error handling: listeners to add-on download routines will
now handle runtime errors.
* Socket error handling: if Internet becomes disconnected while
downloading add-ons, NVDA will raise an exception to communicate this
fact. This error will also be handled by download routine listeners.
* Project Meteor UI and tests: you can (finally) test Project Meteor
using the graphical user interface. After installing this try build,
when you check for add-on updates, NVDA will present a dialog called
"Project Meteor add-on update check". This is done for obvious reason:
to help people identify that this is work in progress. When you do
select add-ons to update, you will then be greeted with the progress
dialog that's quite different than what you are used to: a single
progress dialog showing update download status. But that's not the
biggest change: previously you were used to seeing download and update
dialogs one after the other; not anymore: if you are downloading
multiple add-ons, download progress will be shown, followed by update
dialog once ALL add-ons are downloaded. Don't worry if the dialog text
is not what you were expecting - this will be fixed in a future try
build. To accompany GUI changes, a new function was added to test the
UI portion
(globalPlugins.addonUpdater.addonUpdateProc.test_downloadAndInstallAdd
onUpdatesUI, taking the list of update records, explained below).
* Add-on update record: a new class
(addonUpdateProc.AddonUpdateRecord) is now available to record update
metadata such as summary, installed version, update version, update
URL, compatibility range, among others. This lays the foundation for
further integration testing (currently the UI portion of this try
build uses older update dictionary to store update metadata; this will
change in a future try build to use update records directly) and other
future possibilities (one possibility is "update check protocol" where
Add-on Updater could support multiple ways to obtain add-on update
metadata, chiefly from multiple sources; this requires refactoring current add-on update check facility).

Things to be aware of:

* Add-on versions are shown as 0.0 (testing): this is meant to provide
compatibility with current update check facility. I plan to allow
Add-on Updater to show you the actually installed add-on version in a
future try build.
* Ad-on install errors are not handled (planned): sometimes NVDA may
present messages such as compatibility error if the add-on is deemed incompatible.
The foundation to handle cases like this is present - the UI for it
will be shown in a future try build.
* Add-on Updater update is offered after installing this try build (no
change): to resolve this, just before installing the linked try build,
tell NVDA to not offer updates to Add-on Updater. This bug will be
resolved once Project Meteor is done and becomes part of a future
Add-on Updater stable release.

This try build is of a sufficient quality to be tested by advanced
users (a message about Project Meteor will be sent to NVDA users list
once I finish translating this entire thread to a form understandable
by users). Feedback is appreciated.

Cheers,

Jsoeph






 

Hi all,

The bug reported by Noelia (some add-on metadata dictionary entries do not have certain keys) is now fixed in July 5th try buid: https://github.com/josephsl/addonUpdater/releases/download/22.07/addonUpdater-tryProjectMeteor20220705.nvda-addon

Note: if no errors are found, Project Meteor core will be integrated into main branch this weekend, with UI portion coming later.

Cheers,

Joseph


Noelia Ruiz
 

Hi:

Updates and downloads are super comfortable now. For any reason,
sometimes I've got an error related to emoticons add-on, to config
profile switch and a key available in emoticons add-on while upating,
but this error is not longer present. No idea.
Also, I've disabled controlUsageAssistant and it's enabled after update.
Hope this work can be finished and even may emulate features planned
for the store like testing SHA-256 or signatures (this last one just
proposed). Cheers

2022-07-05 14:05 GMT+02:00, Joseph Lee <joseph.lee22590@...>:

Hi all,

The bug reported by Noelia (some add-on metadata dictionary entries do not
have certain keys) is now fixed in July 5th try buid:
https://github.com/josephsl/addonUpdater/releases/download/22.07/addonUpdater-tryProjectMeteor20220705.nvda-addon

Note: if no errors are found, Project Meteor core will be integrated into
main branch this weekend, with UI portion coming later.

Cheers,

Joseph






 

Hi,
Hashes and signature checks: foundations to check at least SHA256 is present in try builds - it requires both a client side and server side change, although with the upcoming datastore, only the client side needs to change.
As for project completion, basically Project Meteor is complete - I'm adding the user interface for it as part of the integration test. I expect to declare feature complete for Project Meteor with the next try build (later this week).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Tuesday, July 5, 2022 1:02 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Add-on Updater: announcing Project Meteor to refactor add-on download and install routines

Hi:

Updates and downloads are super comfortable now. For any reason, sometimes I've got an error related to emoticons add-on, to config profile switch and a key available in emoticons add-on while upating, but this error is not longer present. No idea.
Also, I've disabled controlUsageAssistant and it's enabled after update.
Hope this work can be finished and even may emulate features planned for the store like testing SHA-256 or signatures (this last one just proposed). Cheers

2022-07-05 14:05 GMT+02:00, Joseph Lee <joseph.lee22590@...>:
Hi all,

The bug reported by Noelia (some add-on metadata dictionary entries do
not have certain keys) is now fixed in July 5th try buid:
https://github.com/josephsl/addonUpdater/releases/download/22.07/addon
Updater-tryProjectMeteor20220705.nvda-addon

Note: if no errors are found, Project Meteor core will be integrated
into main branch this weekend, with UI portion coming later.

Cheers,

Joseph






 

Hi all,

July 7th try build is now available: https://github.com/josephsl/addonUpdater/releases/download/22.07/addonUpdater-tryProjectMeteor20220707.nvda-addon

Changes from the July 5th build:

  • Completely rewritten Add-on Updater interface internals. The biggest change (at the source code) is that the add-on update downloader class is now gone, replaced by the newly implemented add-on download and install functions.
  • Download progress: progress beeps for individual add-on downloads is gone, but that's only a small sacrifice compared to what we have now: as add-ons are downloaded, the name of the add-on being downloaded will be shown.
  • Removed test code for Project Meteor UI tests as you can now use the Add-on Updater interface to test this project. The "Project Meteor" text stil remains in add-on update check dialog for now.
  • Add-on update records: almost all components of Add-on Updater will now use the newly defined add-on update record class. The only exception is the actual add-on updates dialog but that too will use the update record class in a future try build.
  • Install error dialogs such as compatibility error dialog are once again shown when appropriate.
  • Moved automatic add-on download and install code to extended add-on handler module (for an obvious reason to be revealed soon).

Things to be aware of:

  • Add-on versions are shown as "0.0": I hope to resolve this as soon as this weekend.
  • Delay when downloading some add-ons (cannot fix): sometimes you may notice that Add-on Updater may appear to do nothing when downloading some add-ons, caused by a delay when fetching add-on packages. Don't worry about this.

Thanks (feedback is always welcome).

Cheers,

Joseph


 

Hi,

By the way, if you are using an installed copy of NVDA, after installing today’s try build, you will be greeted with a surprise around this time tomorrow (at the latest). Read what the message will say if add-on updates become available then. I’ll talk about it when I release the next try build.

Cheers,

Joseph

 

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Joseph Lee via groups.io
Sent: Thursday, July 7, 2022 12:58 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Add-on Updater: announcing Project Meteor to refactor add-on download and install routines

 

Hi all,

July 7th try build is now available: https://github.com/josephsl/addonUpdater/releases/download/22.07/addonUpdater-tryProjectMeteor20220707.nvda-addon

Changes from the July 5th build:

  • Completely rewritten Add-on Updater interface internals. The biggest change (at the source code) is that the add-on update downloader class is now gone, replaced by the newly implemented add-on download and install functions.
  • Download progress: progress beeps for individual add-on downloads is gone, but that's only a small sacrifice compared to what we have now: as add-ons are downloaded, the name of the add-on being downloaded will be shown.
  • Removed test code for Project Meteor UI tests as you can now use the Add-on Updater interface to test this project. The "Project Meteor" text stil remains in add-on update check dialog for now.
  • Add-on update records: almost all components of Add-on Updater will now use the newly defined add-on update record class. The only exception is the actual add-on updates dialog but that too will use the update record class in a future try build.
  • Install error dialogs such as compatibility error dialog are once again shown when appropriate.
  • Moved automatic add-on download and install code to extended add-on handler module (for an obvious reason to be revealed soon).

Things to be aware of:

  • Add-on versions are shown as "0.0": I hope to resolve this as soon as this weekend.
  • Delay when downloading some add-ons (cannot fix): sometimes you may notice that Add-on Updater may appear to do nothing when downloading some add-ons, caused by a delay when fetching add-on packages. Don't worry about this.

Thanks (feedback is always welcome).

Cheers,

Joseph


Noelia Ruiz
 

Hi:

I've tested this again. And when an add-on is disabled and then
updated, it becomes enabled.
Cheers

2022-07-07 22:02 GMT+02:00, Joseph Lee <joseph.lee22590@...>:

Hi,

By the way, if you are using an installed copy of NVDA, after installing
today’s try build, you will be greeted with a surprise around this time
tomorrow (at the latest). Read what the message will say if add-on updates
become available then. I’ll talk about it when I release the next try
build.

Cheers,

Joseph



From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Joseph Lee via groups.io
Sent: Thursday, July 7, 2022 12:58 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Add-on Updater: announcing Project Meteor to
refactor add-on download and install routines



Hi all,

July 7th try build is now available:
https://github.com/josephsl/addonUpdater/releases/download/22.07/addonUpdater-tryProjectMeteor20220707.nvda-addon

Changes from the July 5th build:

* Completely rewritten Add-on Updater interface internals. The biggest
change (at the source code) is that the add-on update downloader class is
now gone, replaced by the newly implemented add-on download and install
functions.
* Download progress: progress beeps for individual add-on downloads is gone,
but that's only a small sacrifice compared to what we have now: as add-ons
are downloaded, the name of the add-on being downloaded will be shown.
* Removed test code for Project Meteor UI tests as you can now use the
Add-on Updater interface to test this project. The "Project Meteor" text
stil remains in add-on update check dialog for now.
* Add-on update records: almost all components of Add-on Updater will now
use the newly defined add-on update record class. The only exception is the
actual add-on updates dialog but that too will use the update record class
in a future try build.
* Install error dialogs such as compatibility error dialog are once again
shown when appropriate.
* Moved automatic add-on download and install code to extended add-on
handler module (for an obvious reason to be revealed soon).

Things to be aware of:

* Add-on versions are shown as "0.0": I hope to resolve this as soon as this
weekend.
* Delay when downloading some add-ons (cannot fix): sometimes you may notice
that Add-on Updater may appear to do nothing when downloading some add-ons,
caused by a delay when fetching add-on packages. Don't worry about this.

Thanks (feedback is always welcome).

Cheers,

Joseph









 

Hi,
This cannot be fixed easily as changes were made to NVDA Core that effectively enables newly installed (in our case, updated) add-ons if disabled before. For now this is considered can't fix.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Thursday, July 7, 2022 9:56 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Add-on Updater: announcing Project Meteor to refactor add-on download and install routines

Hi:

I've tested this again. And when an add-on is disabled and then updated, it becomes enabled.
Cheers

2022-07-07 22:02 GMT+02:00, Joseph Lee <joseph.lee22590@...>:
Hi,

By the way, if you are using an installed copy of NVDA, after
installing today’s try build, you will be greeted with a surprise
around this time tomorrow (at the latest). Read what the message will
say if add-on updates become available then. I’ll talk about it when I
release the next try build.

Cheers,

Joseph



From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io>
On Behalf Of Joseph Lee via groups.io
Sent: Thursday, July 7, 2022 12:58 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Add-on Updater: announcing Project Meteor
to refactor add-on download and install routines



Hi all,

July 7th try build is now available:
https://github.com/josephsl/addonUpdater/releases/download/22.07/addon
Updater-tryProjectMeteor20220707.nvda-addon

Changes from the July 5th build:

* Completely rewritten Add-on Updater interface internals. The biggest
change (at the source code) is that the add-on update downloader class
is now gone, replaced by the newly implemented add-on download and
install functions.
* Download progress: progress beeps for individual add-on downloads is gone,
but that's only a small sacrifice compared to what we have now: as
add-ons are downloaded, the name of the add-on being downloaded will be shown.
* Removed test code for Project Meteor UI tests as you can now use the
Add-on Updater interface to test this project. The "Project Meteor"
text stil remains in add-on update check dialog for now.
* Add-on update records: almost all components of Add-on Updater will now
use the newly defined add-on update record class. The only exception
is the actual add-on updates dialog but that too will use the update
record class in a future try build.
* Install error dialogs such as compatibility error dialog are once again
shown when appropriate.
* Moved automatic add-on download and install code to extended add-on
handler module (for an obvious reason to be revealed soon).

Things to be aware of:

* Add-on versions are shown as "0.0": I hope to resolve this as soon as this
weekend.
* Delay when downloading some add-ons (cannot fix): sometimes you may notice
that Add-on Updater may appear to do nothing when downloading some
add-ons, caused by a delay when fetching add-on packages. Don't worry about this.

Thanks (feedback is always welcome).

Cheers,

Joseph









Luke Davis
 

Joseph Lee wrote:

This cannot be fixed easily as changes were made to NVDA Core that effectively enables newly installed (in our case, updated) add-ons if disabled before.
I think having an add-on updated that is disabled, and then having it suddenly enabled, would be unexpected UX and should be avoided if at all possible.
It may be NVDA's fault that this happens, but if Updater is what provokes it, it becomes Updater's issue to address IMHO.

You could solve it by declining to update add-ons that are user disabled. That would not apply to add-ons that were disabled by NVDA itself for compatibility reasons.
(E.g. a disabled checkbox: an update is available, but this add-on can't be updated because you have disabled it.)

Alternatively a warning in a separate dialog before completion of update.
"""Warning! Add-on X was disabled. If you update it now it will be re-enabled. Continue updating add-on X? Yes | No"""


Granted you would have a chicken and egg problem with incompatible add-ons, because you couldn't determine if they were disabled prior to NVDA's compatibility disablement, but in that case updating them and letting them be re-enabled would be preferable UX.

Luke


 

Hi,
Here's the reason why updating disabled add-ons re-enables them:
https://github.com/nvaccess/nvda/pull/12792

In fact, even if Add-on Updater and similar add-ons install updates for
disabled add-ons, a cleanup action is performed which removes names of
add-ons no longer present from disabled add-ons set. I may need to do some
more investigations into this matter, but as far as I know, it's a change to
NVDA Core so Add-on Updater may need to do something about it (this change
was introduced in NVDA 2021.3).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Luke Davis
Sent: Thursday, July 7, 2022 10:24 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Add-on Updater: announcing Project Meteor to
refactor add-on download and install routines

Joseph Lee wrote:

This cannot be fixed easily as changes were made to NVDA Core that
effectively enables newly installed (in our case, updated) add-ons if
disabled before.

I think having an add-on updated that is disabled, and then having it
suddenly enabled, would be unexpected UX and should be avoided if at all
possible.
It may be NVDA's fault that this happens, but if Updater is what provokes
it, it becomes Updater's issue to address IMHO.

You could solve it by declining to update add-ons that are user disabled.
That would not apply to add-ons that were disabled by NVDA itself for
compatibility reasons.
(E.g. a disabled checkbox: an update is available, but this add-on can't be
updated because you have disabled it.)

Alternatively a warning in a separate dialog before completion of update.
"""Warning! Add-on X was disabled. If you update it now it will be
re-enabled.
Continue updating add-on X? Yes | No"""


Granted you would have a chicken and egg problem with incompatible add-ons,
because you couldn't determine if they were disabled prior to NVDA's
compatibility disablement, but in that case updating them and letting them
be re-enabled would be preferable UX.

Luke


Noelia Ruiz
 

I think that a checkbox maybe provided to configure if addonUpdater
should update disabled add-ons.
Also, I think that this add-on has a great potential with the new
rutines. So, why not to use it to search all available add-ons making
a proof of concept of the store, creating a similar repo with json
files and so on?
This maybe easy, since with an issue form on GitHub, providing the
add-on name and version etc, the json canbe created with GitHub
Actions, even with sha-256 automatically generated.
Just an idea for testing.


2022-07-08 7:24 GMT+02:00, Luke Davis <luke@...>:

Joseph Lee wrote:

This cannot be fixed easily as changes were made to NVDA Core that
effectively enables newly installed (in our case, updated) add-ons if
disabled before.
I think having an add-on updated that is disabled, and then having it
suddenly
enabled, would be unexpected UX and should be avoided if at all possible.
It may be NVDA's fault that this happens, but if Updater is what provokes
it, it
becomes Updater's issue to address IMHO.

You could solve it by declining to update add-ons that are user disabled.
That
would not apply to add-ons that were disabled by NVDA itself for
compatibility
reasons.
(E.g. a disabled checkbox: an update is available, but this add-on can't be

updated because you have disabled it.)

Alternatively a warning in a separate dialog before completion of update.
"""Warning! Add-on X was disabled. If you update it now it will be
re-enabled.
Continue updating add-on X? Yes | No"""


Granted you would have a chicken and egg problem with incompatible add-ons,

because you couldn't determine if they were disabled prior to NVDA's
compatibility disablement, but in that case updating them and letting them
be
re-enabled would be preferable UX.

Luke








 

Hi,
Store idea: such an add-on already exists (if I remember correctly). Because Add-on Updater is strictly a client to fetch update packages, I am intentionally not going the store route for now. But one thing is for certain: if the latest protocols work as intended, provided that folks agree, I'll add Spanish community repo as an add-on source and made configurable soon (the full power of this feature requires NVDA 2022.1 or later, specifically because it includes much better command-line handling). Even then, Add-on Updater is not going to become a store (at this time) as the add-on is really a proof of concept for NVDA issue 3208 (the upcoming protocols work will also support NV Access datastore in the future).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Thursday, July 7, 2022 11:37 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Add-on Updater: announcing Project Meteor to refactor add-on download and install routines

I think that a checkbox maybe provided to configure if addonUpdater should update disabled add-ons.
Also, I think that this add-on has a great potential with the new rutines. So, why not to use it to search all available add-ons making a proof of concept of the store, creating a similar repo with json files and so on?
This maybe easy, since with an issue form on GitHub, providing the add-on name and version etc, the json canbe created with GitHub Actions, even with sha-256 automatically generated.
Just an idea for testing.


2022-07-08 7:24 GMT+02:00, Luke Davis <luke@...>:
Joseph Lee wrote:

This cannot be fixed easily as changes were made to NVDA Core that
effectively enables newly installed (in our case, updated) add-ons if
disabled before.
I think having an add-on updated that is disabled, and then having it
suddenly enabled, would be unexpected UX and should be avoided if at
all possible.
It may be NVDA's fault that this happens, but if Updater is what
provokes it, it becomes Updater's issue to address IMHO.

You could solve it by declining to update add-ons that are user disabled.
That
would not apply to add-ons that were disabled by NVDA itself for
compatibility reasons.
(E.g. a disabled checkbox: an update is available, but this add-on
can't be

updated because you have disabled it.)

Alternatively a warning in a separate dialog before completion of update.
"""Warning! Add-on X was disabled. If you update it now it will be
re-enabled.
Continue updating add-on X? Yes | No"""


Granted you would have a chicken and egg problem with incompatible
add-ons,

because you couldn't determine if they were disabled prior to NVDA's
compatibility disablement, but in that case updating them and letting
them be re-enabled would be preferable UX.

Luke








 

Hi,
As for a checkbox to tell Add-on Updater to not update disabled add-ons: you can achieve this by telling Add-on Updater to not update selected add-ons provided that you know the name of the disabled add-on. If I get to implementing a dedicated option for updating disabled add-ons, it must wait until Project Meteor is fully operational (almost there; the last step in making this project operational is releasing a stable version of Add-on Updater with Project Meteor included, tentatively scheduled for August).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Joseph Lee via groups.io
Sent: Friday, July 8, 2022 12:06 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Add-on Updater: announcing Project Meteor to refactor add-on download and install routines

Hi,
Store idea: such an add-on already exists (if I remember correctly). Because Add-on Updater is strictly a client to fetch update packages, I am intentionally not going the store route for now. But one thing is for certain: if the latest protocols work as intended, provided that folks agree, I'll add Spanish community repo as an add-on source and made configurable soon (the full power of this feature requires NVDA 2022.1 or later, specifically because it includes much better command-line handling). Even then, Add-on Updater is not going to become a store (at this time) as the add-on is really a proof of concept for NVDA issue 3208 (the upcoming protocols work will also support NV Access datastore in the future).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Thursday, July 7, 2022 11:37 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Add-on Updater: announcing Project Meteor to refactor add-on download and install routines

I think that a checkbox maybe provided to configure if addonUpdater should update disabled add-ons.
Also, I think that this add-on has a great potential with the new rutines. So, why not to use it to search all available add-ons making a proof of concept of the store, creating a similar repo with json files and so on?
This maybe easy, since with an issue form on GitHub, providing the add-on name and version etc, the json canbe created with GitHub Actions, even with sha-256 automatically generated.
Just an idea for testing.


2022-07-08 7:24 GMT+02:00, Luke Davis <luke@...>:
Joseph Lee wrote:

This cannot be fixed easily as changes were made to NVDA Core that
effectively enables newly installed (in our case, updated) add-ons if
disabled before.
I think having an add-on updated that is disabled, and then having it
suddenly enabled, would be unexpected UX and should be avoided if at
all possible.
It may be NVDA's fault that this happens, but if Updater is what
provokes it, it becomes Updater's issue to address IMHO.

You could solve it by declining to update add-ons that are user disabled.
That
would not apply to add-ons that were disabled by NVDA itself for
compatibility reasons.
(E.g. a disabled checkbox: an update is available, but this add-on
can't be

updated because you have disabled it.)

Alternatively a warning in a separate dialog before completion of update.
"""Warning! Add-on X was disabled. If you update it now it will be
re-enabled.
Continue updating add-on X? Yes | No"""


Granted you would have a chicken and egg problem with incompatible
add-ons,

because you couldn't determine if they were disabled prior to NVDA's
compatibility disablement, but in that case updating them and letting
them be re-enabled would be preferable UX.

Luke








Noelia Ruiz
 

OK, the checkbox may not b needed. We may create an issue to fix this in NVDA.

2022-07-08 9:10 GMT+02:00, Joseph Lee <joseph.lee22590@...>:

Hi,
As for a checkbox to tell Add-on Updater to not update disabled add-ons: you
can achieve this by telling Add-on Updater to not update selected add-ons
provided that you know the name of the disabled add-on. If I get to
implementing a dedicated option for updating disabled add-ons, it must wait
until Project Meteor is fully operational (almost there; the last step in
making this project operational is releasing a stable version of Add-on
Updater with Project Meteor included, tentatively scheduled for August).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Joseph Lee via groups.io
Sent: Friday, July 8, 2022 12:06 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Add-on Updater: announcing Project Meteor to
refactor add-on download and install routines

Hi,
Store idea: such an add-on already exists (if I remember correctly). Because
Add-on Updater is strictly a client to fetch update packages, I am
intentionally not going the store route for now. But one thing is for
certain: if the latest protocols work as intended, provided that folks
agree, I'll add Spanish community repo as an add-on source and made
configurable soon (the full power of this feature requires NVDA 2022.1 or
later, specifically because it includes much better command-line handling).
Even then, Add-on Updater is not going to become a store (at this time) as
the add-on is really a proof of concept for NVDA issue 3208 (the upcoming
protocols work will also support NV Access datastore in the future).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Noelia Ruiz
Sent: Thursday, July 7, 2022 11:37 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Add-on Updater: announcing Project Meteor to
refactor add-on download and install routines

I think that a checkbox maybe provided to configure if addonUpdater should
update disabled add-ons.
Also, I think that this add-on has a great potential with the new rutines.
So, why not to use it to search all available add-ons making a proof of
concept of the store, creating a similar repo with json files and so on?
This maybe easy, since with an issue form on GitHub, providing the add-on
name and version etc, the json canbe created with GitHub Actions, even with
sha-256 automatically generated.
Just an idea for testing.


2022-07-08 7:24 GMT+02:00, Luke Davis <luke@...>:
Joseph Lee wrote:

This cannot be fixed easily as changes were made to NVDA Core that
effectively enables newly installed (in our case, updated) add-ons if
disabled before.
I think having an add-on updated that is disabled, and then having it
suddenly enabled, would be unexpected UX and should be avoided if at
all possible.
It may be NVDA's fault that this happens, but if Updater is what
provokes it, it becomes Updater's issue to address IMHO.

You could solve it by declining to update add-ons that are user disabled.
That
would not apply to add-ons that were disabled by NVDA itself for
compatibility reasons.
(E.g. a disabled checkbox: an update is available, but this add-on
can't be

updated because you have disabled it.)

Alternatively a warning in a separate dialog before completion of update.
"""Warning! Add-on X was disabled. If you update it now it will be
re-enabled.
Continue updating add-on X? Yes | No"""


Granted you would have a chicken and egg problem with incompatible
add-ons,

because you couldn't determine if they were disabled prior to NVDA's
compatibility disablement, but in that case updating them and letting
them be re-enabled would be preferable UX.

Luke






















Luke Davis
 

Joseph

That's why I think the reasonable direction would be not to even try to update disabled add-ons, unless they were auto-disabled for compatibility reasons.

Or, alternately, to let users know that updating this add-on will re-enable it.

There shouldn't be much of a down side to suspending updates for disabled add-ons.

If the user misses a few updates: no loss, since it was disabled anyway.
If it is re-enabled: only a brief inconvenience, as on next update check, the new version will be found and an update will be offered.

Luke

Joseph Lee wrote:

Hi,
Here's the reason why updating disabled add-ons re-enables them:
https://github.com/nvaccess/nvda/pull/12792

In fact, even if Add-on Updater and similar add-ons install updates for
disabled add-ons, a cleanup action is performed which removes names of
add-ons no longer present from disabled add-ons set. I may need to do some
more investigations into this matter, but as far as I know, it's a change to
NVDA Core so Add-on Updater may need to do something about it (this change
was introduced in NVDA 2021.3).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Luke Davis
Sent: Thursday, July 7, 2022 10:24 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Add-on Updater: announcing Project Meteor to
refactor add-on download and install routines

Joseph Lee wrote:

This cannot be fixed easily as changes were made to NVDA Core that
effectively enables newly installed (in our case, updated) add-ons if
disabled before.

I think having an add-on updated that is disabled, and then having it
suddenly enabled, would be unexpected UX and should be avoided if at all
possible.
It may be NVDA's fault that this happens, but if Updater is what provokes
it, it becomes Updater's issue to address IMHO.

You could solve it by declining to update add-ons that are user disabled.
That would not apply to add-ons that were disabled by NVDA itself for
compatibility reasons.
(E.g. a disabled checkbox: an update is available, but this add-on can't be
updated because you have disabled it.)

Alternatively a warning in a separate dialog before completion of update.
"""Warning! Add-on X was disabled. If you update it now it will be
re-enabled.
Continue updating add-on X? Yes | No"""


Granted you would have a chicken and egg problem with incompatible add-ons,
because you couldn't determine if they were disabled prior to NVDA's
compatibility disablement, but in that case updating them and letting them
be re-enabled would be preferable UX.

Luke












 

Hi,
Yep, and a workaround for this is to tell Add-on Updater to not check for
updates for add-ons you have disabled (I understand that this is very
inconvenient, but I'm open to possibility of implementing a suggestion where
Add-on Updater will record an error and refuse to update disabled add-ons).
Also, it looks like protocols work is going nicely - thanks to Jose-Manuel
(json is public), I have managed to parse Spanish community store format,
and looks like a protocol representation of this catalog should not be that
difficult to implement. I'll talk more about that in an upcoming post.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Luke Davis
Sent: Friday, July 8, 2022 1:17 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Add-on Updater: announcing Project Meteor to
refactor add-on download and install routines

Joseph

That's why I think the reasonable direction would be not to even try to
update disabled add-ons, unless they were auto-disabled for compatibility
reasons.

Or, alternately, to let users know that updating this add-on will re-enable
it.

There shouldn't be much of a down side to suspending updates for disabled
add-ons.

If the user misses a few updates: no loss, since it was disabled anyway.
If it is re-enabled: only a brief inconvenience, as on next update check,
the new version will be found and an update will be offered.

Luke

Joseph Lee wrote:

Hi,
Here's the reason why updating disabled add-ons re-enables them:
https://github.com/nvaccess/nvda/pull/12792

In fact, even if Add-on Updater and similar add-ons install updates
for disabled add-ons, a cleanup action is performed which removes
names of add-ons no longer present from disabled add-ons set. I may
need to do some more investigations into this matter, but as far as I
know, it's a change to NVDA Core so Add-on Updater may need to do
something about it (this change was introduced in NVDA 2021.3).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io>
On Behalf Of Luke Davis
Sent: Thursday, July 7, 2022 10:24 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Add-on Updater: announcing Project Meteor
to refactor add-on download and install routines

Joseph Lee wrote:

This cannot be fixed easily as changes were made to NVDA Core that
effectively enables newly installed (in our case, updated) add-ons if
disabled before.

I think having an add-on updated that is disabled, and then having it
suddenly enabled, would be unexpected UX and should be avoided if at
all possible.
It may be NVDA's fault that this happens, but if Updater is what
provokes it, it becomes Updater's issue to address IMHO.

You could solve it by declining to update add-ons that are user disabled.
That would not apply to add-ons that were disabled by NVDA itself for
compatibility reasons.
(E.g. a disabled checkbox: an update is available, but this add-on
can't be updated because you have disabled it.)

Alternatively a warning in a separate dialog before completion of update.
"""Warning! Add-on X was disabled. If you update it now it will be
re-enabled.
Continue updating add-on X? Yes | No"""


Granted you would have a chicken and egg problem with incompatible
add-ons, because you couldn't determine if they were disabled prior to
NVDA's compatibility disablement, but in that case updating them and
letting them be re-enabled would be preferable UX.

Luke