Comment 1 by jteh on 2013-12-23 00:06
I don't follow this. Updating an add-on always removes the old version after restarting NVDA, which is the only safe time to remove an add-on. Can you please provide an example scenario where you need specific code in installTasks for this?

Comment 2 by norrumar on 2013-12-26 11:03
Hi Mesar and All: I think this ticket should be closed.
Imo you are talking about incompatible add-ons which must be removed to install a new one, but when their names are different. For instance: teamViewer and teamViewerNVDASupport.
This happens when the old add-on isn't named according to our community guidelines.
Thanks.

Comment 4 by MHameed on 2014-02-05 01:54

Sorry for the delay, and not explaining my reasoning more clearly previously.

An addon is often written by an author to solve a particular problem for themselves or for someone they know.
As they test it and get more users, they think ok why not submit it to the community.

As part of the review/improvement process, we usually will have to change the addon name to match the addon naming guidelines, to fit in better with translation system and with the addon website requirements.

What is happening now, is that for each addon that needs this treatment, we have the same snippet of code, dialog and same translatable messages.
If this function could be accepted into nvda code, then those messages would only have to be translated once, as part of main nvda.po, also maintaining and improving the function becomes easier.
Not every addon will need it, but for those that do, it will be easier.

I hope I put my case more succinctly.

thanks,

Comment 5 by norrumar (in reply to comment 4) on 2014-02-05 06:50
Replying to MHameed:
OK Mesar. If you want to add this in NVDA's core, I agree with you. It would be easier for add-ons authors to specify incompatible add-ons. Perhaps it could be done including an optiona field in the manifest.ini file, where a list of add-ons which should be removed before an installation could be specified.
Just an idea.
Thanks.

Sorry for the delay, and not explaining my reasoning more clearly previously.

An addon is often written by an author to solve a particular problem for themselves or for someone they know.

As they test it and get more users, they think ok why not submit it to the community.

As part of the review/improvement process, we usually will have to change the addon name to match the addon naming guidelines, to fit in better with translation system and with the addon website requirements.

What is happening now, is that for each addon that needs this treatment, we have the same snippet of code, dialog and same translatable messages.

If this function could be accepted into nvda code, then those messages would only have to be translated once, as part of main nvda.po, also maintaining and improving the function becomes easier.

Not every addon will need it, but for those that do, it will be easier.

I hope I put my case more succinctly.

thanks,

Comment 6 by jteh on 2014-02-05 07:18
While I'm sure this is nice, surely this is the user's responsibility. If they install an add-on from somewhere else and then download an add-on with a different name from the official site, we can expect them to remove the old one. This issue is not unique to NVDA add-ons.

Are you requesting that the older add-on be removed automatically or are you requesting that the user be informed that they should remove it? If the latter, I guess we could consider a more generic "conflicts" mechanism where an add-on is marked as conflicting with another. Imo, "superceded" or "replaces" is far too specific and doesn't justify its own special support.

Comment 7 by norrumar (in reply to comment 6) on 2014-02-05 07:33
Replying to jteh:
Imo users should be informed about incompatible add-ons when installing a new one. Some authors use onInstall function for this: when an incompatible add-on is found, it's notified and the user can answer if the old add-on will be removed.

While I'm sure this is nice, surely this is the user's responsibility. If they install an add-on from somewhere else and then download an add-on with a different name from the official site, we can expect them to remove the old one. This issue is not unique to NVDA add-ons.

Are you requesting that the older add-on be removed automatically or are you requesting that the user be informed that they should remove it? If the latter, I guess we could consider a more generic "conflicts" mechanism where an add-on is marked as conflicting with another. Imo, "superceded" or "replaces" is far too specific and doesn't justify its own special support.

Comment 8 by MHameed (in reply to comment 6) on 2014-02-15 10:45
Replying to jteh:

Are you requesting that the older add-on be removed automatically

or are you requesting that the user be informed that they should remove it?

We remind them that the two addons are incompatible, and that the new one superseeds the functionality in the old addon.
We ask for their consent before removing the old addon.
My current consern is to remove duplicated translatable messages.
See t3731 branch in git.

If the latter, I guess we could consider a more generic "conflicts" mechanism where an add-on is marked as conflicting with another.

Imo, "superceded" or "replaces" is far too specific and doesn't justify its own special support.

Having a generic conflict mechanism would be useful, at present superceded/replaces is the only thing we have needed to handle.

Maybe we should arrange a voice call/irc chat to spec out requirements for a conflict mechanism.

Comment 9 by zahari_bgr on 2014-02-15 12:08
If you take this approach, please consider add-on dependencies too - it is not an issue at this time, but in the future there could be an add-on, that depends of some functions of another add-on, etc. There could be other dependencies, like NVDA version, etc.
It will be good if it is handled in some centralized way. I agree with norrumar (in comment 5) that the manifest.ini file is a good place for specifying such information.

I am in agreement with @jcsteh's following quote:
"While I'm sure this is nice, surely this is the user's responsibility. If they install an add-on from somewhere else and then download an add-on with a different name from the official site, we can expect them to remove the old one. This issue is not unique to NVDA add-ons."
I am not too sure of whether we should still pursue implementing this, but then again, I'll leave it at this - CC @josephsl, @nvdaes, @derekriemer and other add-on experts.

I feel like this is the responsibility of the uninstalling addon.

Hi,

Technical: an add-on can find out where an add-on lives and ask for add-on removal if told to do so.

I'd say it's something users should be told about and asked for confirmation before the newer add-on removes an incompatible add-on. As for what Zahari pointed out, this might bring up dependency problem where another add-on may depend on features provided by the deprecated add-on, and this is when communication between authors is the key. As for an add-on depending on features from a specific version of NVDA, there is a ticket out there that discusses this (if I'm correct).

For now, I'll close this, as this is more towards something that the add-ons community should discuss in detail. Thanks.