-
-
Notifications
You must be signed in to change notification settings - Fork 634
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow addons to specify minimum compatible version of NVDA #6275
Comments
Happy enough for this to be done. The reason this wasn't done initially
is that snapshots present a problem, since the version string for
snapshots is entirely different to the versioning for releases. However,
#6205 introduces year/major/minor version attributes which can be used
for this comparison.
|
CC @derekriemer, @nvdaes, @jcsteh and other add-on writers. |
Hi, Blocked by #6205. Design:
Thanks. |
Hi, Few issues and questions to consider:
Thanks. |
Hi, I'm thinking what happens with add-ons like a Word add-on, that |
This has been abandoned for a little while now. Is someone intending to implement this? |
Hi, I’m tempted to label this for “good for new dev”. Thanks.
|
This is going to be an important bit of work for 2018.2 as so many large
changes will be going in (wxPython 4, multi category settings, speech
refactor).
I think we should take the approach of Windows store, which is two values:
minimumRequiredVersion, and lastVersionTested.
Newer versions of NVDA can refuse to load add-ons if they have a
lastVersionTested lower than the current version or it is missing.
NVDA can also refuse to load add-ons with a minimRequiredVersion higher
than the current version... though obviously this would not have an
impact until at least 2018.3 actually existed.
|
I propose minimumNVDAVersion and lastTestedNVDAVersion in order not to create ambiguity with add-on version numbers itself. Both minimum and required is not scrtictly necessary I belief. Anyhow, I'm happy to take this issue. |
While looking at the addonHandler code, I noticed that the Addon object has quite a few magic properties while not inheriting from AutoPropertyObject. Is there a particular reason for this? |
I don't believe there is a good reason. Simply just history I guess. We
tended to only use AutoPropertyObject for NVDAObjects / TextInfos
(representations of content). We never considered using it for other
arbitrary objects.
|
I also find myself wondering occasionally whether those `_get_foo` magic
properties were really such a good idea. The problem with magic is that
it's a barrier to entry and it's hard to work out where to document it
because it's not explicit. Still, that's out of scope for this issue. :)
|
…s, and use this information to disable incompatible add-ons (PR #8006) Closes #6275 * Allow setting minimum required NVDA version and last tested NVDA version in an add-on manifest, and use them to block add-ons from loading if desired. * Move the version info retrieval code from appModuleHandler to fileUtils * moved addonHandler into a package * Fix scaling issues in the addon gui * GUI additions: * Show unknown compatibility addons dialog on startup if there are addons already installed that are untested. * When attempting to install an incompatible / untested addon, a prompt is shown to block / confirm the installation. * When attempting to install a new version of NVDA with untested addons present, the user is warned that these addons will be disabled after installation. The untested addons can be listed, and any that should not be disabled can be flagged. * During install of NVDA the user must check a box to confirm that they understand that their nvda installation contains addons that may not have been tested and will be disabled after the installation of NVDA. * Addon manager GUI changes: * Buttons that relate to the currently selected add-on are arranged vertically to the right of the add-on list * Buttons that relate to the addon manager more generally are arranged horizontally at the bottom of the dialog. * Fixed a bug in AutoWidthColumnCheckListCtrl which was stopping NVDA from being able to exit * Update userguide and developerGuide * Update changes file for #8006
For function complexity note in addonGui.installAddon, this is caused by installer UI. Thus find a way to separate the instlaler from the UI. For E402 in update check, remant from nvaccess#6275, so no need to worry.
With the
@script
decorator and more upcoming changes that I hope to introduce to the addon system, it will be necessary for addons to specify what versions of NVDA they support so as to be able to alert users at installation time that their NVDA is not compatible.I recommend a minimum_version key in the manifest.
Obviously this will not help existing versions of NVDA and addons, but the sooner we add it, the sooner it will be useful in future :)
The text was updated successfully, but these errors were encountered: