[GUI Plugin] Plugin Updater **Deprecated**

[Loeffel]

@kiwidude
For the handling of newly integrated plugins as the updater you could invent a routine. What should this routine do?

• On first start after installation (or with every start depending if the second routine doesn't exists) check if a deprecated plugin has been installed.
• deinstall the deprecated plugin/s
• give message of deinstallation
• restart Calibre

The second routine is part of the updater, it checks if the deprecated function is to be installed and denies installation and gives error message.

I know, this is only possible if the plugins are installed under their official names, but I assume that nearly everyone will have them installed this way. The last remaining are just calculated losses.

[theducks]

I vote for NOT putting the Plug-ins into Main Calibre as it will limit PI repair to the release cycle (waiting a week is H*ll )
OTOH If it is only the Distribution of the PI that is included with a normal release, then relocating (and maybe applying a visual 'style' to the label that indicates a normal part of Calibre) makes manual, Mid-Release (of Calibre) PI upgrades available.

[Dopedangel]

Originally Posted by theducks

I vote for NOT putting the Plug-ins into Main Calibre as it will limit PI repair to the release cycle (waiting a week is H*ll )
OTOH If it is only the Distribution of the PI that is included with a normal release, then relocating (and maybe applying a visual 'style' to the label that indicates a normal part of Calibre) makes manual, Mid-Release (of Calibre) PI upgrades available.

Why would he put plugin update into calibre if plugins won't be updated separately

[kiwidude]

@Loeffel - the theory of it sounds good but I'm not sure how easy it is to implement in terms of the timing of plugins being loaded into Calibre, in-built versus custom plugins, handling of duplicate names etc. I'm hoping Kovid can share his insight/experience on that as to what would "work" with the current code and obviously support a change if it is thought appropriate to do so.

@theducks - haha, too funny. You know you could run from source if you don't want to wait a week, right? Besides, you guys are lucky that I have been taking a break from work for a while to put these plugin updates out so frequently. That will definitely change once I start work again. Plus by being in Calibre it means there is the possibility (however remote since all are busy with their own stuff) other Calibre developers could work on any fixes/additions rather than it just being the original plugin developer. So it wouldn't all be bad...

And yes it is only Plugin Updater and Find Duplicates that I personally see being directly added to Calibre sooner rather than later.

[theducks]

Originally Posted by Dopedangel

Why would he put plugin update into calibre if plugins won't be updated separately

Because there are people running really down rev versions of Calibre who don't update because of system dependency issues (I assume the OS upgrade would destroy a really expensive, mission critical piece of software with no (free) updates available)
(Why would they be running Calibre on a Mission critical system in the first place?)

[theducks]

Originally Posted by kiwidude

@theducks - haha, too funny. You know you could run from source if you don't want to wait a week, right? Besides, you guys are lucky that I have been taking a break from work for a while to put these plugin updates out so frequently. That will definitely change once I start work again. Plus by being in Calibre it means there is the possibility (however remote since all are busy with their own stuff) other Calibre developers could work on any fixes/additions rather than it just being the original plugin developer. So it wouldn't all be bad...

I could never get it (RFS) to work on my XP system (no astirisk). chaley coached me, too

[kovidgoyal]

I committed code that will do two things:

1) Ignore any user plugins that have the same name as a builtin plugin, so if a future calibre release gets a builtin plugin with the same name as a user plugin, the user plugin will be ignored. Not only that, the plugin will be silently uninstalled (this is for performance, so that the plugin zip file is not unnecessarily read at each calibre startup)

2) Popup an error message if a user tries to add a plugin with the same name as a builtin plugin

@kiwidude: I'd appreciate it if you could test these two changes as I am rather busy at the moment.

[kiwidude]

@Kovid - thx for that, I will test your changes shortly.

They will handle the situation of a plugin like "Plugin Updater" or "Find Duplicates" becoming part of Calibre nicely, and in that situation it will be appropriate to remove the plugin from the forum plugin index page completely so it will not appear in the plugin updater dialog.

However there is still the other scenario of where a plugin gets renamed or combined into a new plugin. The most recent example is "Kindle Collections" which was previously known as "Create Kindle Collections". I will shortly have an additional scenario of "Goodreads Metadata" and "Goodreads Covers" being replaced by a new metadata source plugin called "Goodreads".

I have made the changes to plugin updater to support a "Deprecated" value on the index page, and placed an additional greyed out section on the plugin index page at the bottom where such plugins will go to "die".

With the changes I have made, if it sees that you have one of these plugins installed, it gets a special icon and appearance as per the attached screenshot. It will show up on the "All", "Update available" and "Installed" views. If you either (a) install it's replacement using Plugin Updater, or (b) uninstall it, then it disappears and will never be visible again on the plugin updater dialog (well unless you reinstalled it manually outside of plugin updater).

I have also added support for multiple uninstall plugin targets, so my Goodreads plugin will have "; Uninstall: Goodreads Metadata,Goodreads Covers" on the index page and both those plugins will get uninstalled. [Note that I will only put that attribute on there when Calibre 0.8 is officially released, as it is valid to have all plugins side by side for users who are just temporarily testing both].

Before I push the new Plugin Updater version, any objections to the above?

[Nyssa]

So if I understand the image correctly, I am being prompted to untinstall "Good Reads metatdata" which is in red?

[kovidgoyal]

I cant tell from the screenshot if you have already done this, but it would be good to have a message saying the plugin should be uninstalled when the user clicks on a deprecated plugin.

Also IMO, having it in red is a little scary. May be better to have it grayed out like firefox does in it s plugin dialog with plugins that no longer work after an update.

[kiwidude]

@Nyssa - depends on your definition of "prompt" but yes, it is a visual warning that you should uninstall it. And in normal usage of the plugin updater (such as installing its replacement) that uninstall will happen automatically. The text that will appear in the description field will tell the user exactly why the plugin has reached this warning state and what they should do about it (such as the name of the replacement plugin or whatever).

I don't want such upgrades to happen automatically because there are people who want to be conservative in upgrading and not necessarily grabbing the latest as soon as it is available. This was the best compromise I could think of to keep the user informed without having plugins disappearing without them knowing why.

[kiwidude]

Originally Posted by kovidgoyal

I cant tell from the screenshot if you have already done this, but it would be good to have a message saying the plugin should be uninstalled when the user clicks on a deprecated plugin.

Yes the tooltip tells you, as well the description for the plugin at the bottom.

Also IMO, having it in red is a little scary. May be better to have it grayed out like firefox does in it s plugin dialog with plugins that no longer work after an update.

The problem is that I already use grey for disabled plugins. Or do you want a compromise of the red icon with grey text?

[kovidgoyal]

Use another color, blue perhaps? After all having a deprecated plugin is not a critical condition, so red seems a little excessive

[kiwidude]

Blue it is.

[Nyssa]

Originally Posted by kiwidude

@Nyssa - depends on your definition of "prompt" but yes, it is a visual warning that you should uninstall it. And in normal usage of the plugin updater (such as installing its replacement) that uninstall will happen automatically. The text that will appear in the description field will tell the user exactly why the plugin has reached this warning state and what they should do about it (such as the name of the replacement plugin or whatever).

I don't want such upgrades to happen automatically because there are people who want to be conservative in upgrading and not necessarily grabbing the latest as soon as it is available. This was the best compromise I could think of to keep the user informed without having plugins disappearing without them knowing why.

Originally Posted by kiwidude

Yes the tooltip tells you, as well the description for the plugin at the bottom.

The problem is that I already use grey for disabled plugins. Or do you want a compromise of the red icon with grey text?

Okay. Cool. It seems like you have all angles coverd, with both a visual cue and an explanation.

Originally Posted by kovidgoyal

Use another color, blue perhaps? After all having a deprecated plugin is not a critical condition, so red seems a little excessive

As an end-user, red would catch my attention more than blue, although I do understand your point of it being a non-critical issue.

Since you will be using blue, please make sure there is a color key added somewhere where the average end-user is likely to read it.

Thank you both so much for all of your hard work! I can not put into words my appreciation for Calibre, its team of developers and those who volunteer their talents. Thank You.