Replies: 2 comments
-
This was to prevent loss of user config / data / licenses etc.
There is the potential for the add-on to never be updated, meanwhile taking up space, and slowing down NVDA startup. When incompatible add-ons are disabled they are "out of sight, out of mind", easy for users to accumulate many unusable add-ons. I'd be hesitant to change this in the short term. However, once the add-on store is available, it would be worth looking at this use-case again: I.E. As a power user I want browse all existing add-ons so I can earmark add-ons of interest for future consideration / installation if they become compatible. |
Beta Was this translation helpful? Give feedback.
-
|
What I do is keep several different flavours of nvda around. Last version
which the add ons I used worked in, the latest alpha, and a portable version
also of the actual latest release as well.
OK its a bit annoying having to switch screenreaders, but it works.
I am also not totally happy with the compatibility being only the manifest,
in some cases at least. There seems no easy way without an intimate
knowledge of Python and NVDA workings, to be able to do anything than suck
it and see, as we used to say, listening for errors or non functioning parts
of the add on.
Brian
***@***.***
Sent via blueyonder.
Please address personal E-mail to:-
***@***.***, putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "Luke Davis" ***@***.***>
To: "nvaccess/nvda" ***@***.***>
Cc: "Subscribed" ***@***.***>
Sent: Monday, May 23, 2022 6:45 AM
Subject: [nvaccess/nvda] Allow installation of incompatible add-ons
(Discussion #13726)
… While working on #13632 via #13673, I began contemplating the reasoning
behind the fact that NVDA does not allow the installation of add-ons which
are either too old, or too new, for the current version of NVDA. That is:
they are incompatible, so it blocks them from being installed. However, if
you already have add-ons installed when you upgrade NVDA, which will be
rendered incompatible by the upgrade, they are not removed--they are
flagged as incompatible and disabled.
But later, if an update is released, and provided you have the Add-On
Updater add-on by @josephsl,when a compatible version of that add-on
arrives: the new version will be installed, and it will be automatically
re-enabled upon the next NVDA restart.
That is a valuable and common-sense feature. But it makes me wonder: why
does NVDA even bother refusing to install incompatible add-ons?
Why not, instead, let them be installed, but mark them incompatible and
disable them, with a warning to the user that this is happening?
That would allow an interesting add-on to be discovered, installed,
and--even though it isn't compatible yet--sit waiting for a compatible
version to be released, at which point it can be updated and automatically
enabled.
My questions are:
1. Are there any particular downsides to changing the approach in this
way?
2. Would NV Access be open to this direction @feerrenrut?
I recently had a situation where this exact scenario occurred for me. I
discovered an add-on I liked, but it was not compatible with 2022.2 alphas
that I was running (I.E. it was incompatible with 2022.1). It was not an
add-on I was very familiar with, but I liked what it could do.
If I had found it while I was running older NVDA, I could have just
installed it and waited for it to catch up. However because it was now
incompatible and could not be installed, all I could do was continue to
manually monitor, to remind myself that I was interested in it
weeks/months later when it got updated.
In this case, I just kept a tab opened to its addons.nvda-project.org
page, so every once in a while I would notice that opened tab, and it
would be brought to mind. It would have been rather easier if I could have
just installed it though.
--
Reply to this email directly or view it on GitHub:
#13726
You are receiving this because you are subscribed to this thread.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
While working on #13632 via #13673, I began contemplating the reasoning behind the fact that NVDA does not allow the installation of add-ons which are either too old, or too new, for the current version of NVDA. That is: they are incompatible, so it blocks them from being installed. However, if you already have add-ons installed when you upgrade NVDA, which will be rendered incompatible by the upgrade, they are not removed--they are flagged as incompatible and disabled.
But later, if an update is released, and provided you have the Add-On Updater add-on by @josephsl,when a compatible version of that add-on arrives: the new version will be installed, and it will be automatically re-enabled upon the next NVDA restart.
That is a valuable and common-sense feature. But it makes me wonder: why does NVDA even bother refusing to install incompatible add-ons?
Why not, instead, let them be installed, but mark them incompatible and disable them, with a warning to the user that this is happening?
That would allow an interesting add-on to be discovered, installed, and--even though it isn't compatible yet--sit waiting for a compatible version to be released, at which point it can be updated and automatically enabled.
My questions are:
I recently had a situation where this exact scenario occurred for me. I discovered an add-on I liked, but it was not compatible with 2022.2 alphas that I was running (I.E. it was incompatible with 2022.1). It was not an add-on I was very familiar with, but I liked what it could do.
If I had found it while I was running older NVDA, I could have just installed it and waited for it to catch up. However because it was now incompatible and could not be installed, all I could do was continue to manually monitor, to remind myself that I was interested in it weeks/months later when it got updated.
In this case, I just kept a tab opened to its addons.nvda-project.org page, so every once in a while I would notice that opened tab, and it would be brought to mind. It would have been rather easier if I could have just installed it though.
Beta Was this translation helpful? Give feedback.
All reactions