Refresh stuff when plugins change

[GoogleCodeExporter]

Sometimes when you change plugins settings (currently, when you enable or 
disable a plugin), it's necessary to refresh the current window.

Examples:

- If you enable or disable a shelf view, you need to refresh the list of views 
to show or hide that plugin.
- If you are editing a book and you enable/disable a Guesser, you need to 
reload the editor to display the new guesser on the list.

We should figure out a way to hook plugins (and maybe plugin categories) to UI 
elements, so that they are refreshed when a plugin/plugin category changes. 

I guess some witchcraft with slots/signals could help here.

Original issue reported on code.google.com by andresgattinoni on 27 Jan 2011 at 2:36

• Blocked on: #52

[GoogleCodeExporter]

I think categories may be the way to go, but I don't really have an idea about 
how to do it ;-)

Original comment by roberto.alsina on 27 Jan 2011 at 3:02

[GoogleCodeExporter]

Well, I'll tell you what I think and you can help me adapt it to PyQT.

We could write a parent PluginCategory class and have all the categories extend 
from that. Then we define an event for the PluginCategory class, let's say 
"categoryPluginsChanged" (or whatever).

On the other side, you make UI elements register listeners for certain events 
of certain categories of plugins. For example, the guessers combobox in the 
book editor (or some sort of interface with the combobox) registers a listener 
for the "categoryPluginsChanged" of the "Guesser" plugin category. When you 
enable/disable a plugin of the Guesser category, the "categoryPluginsChanged" 
event is fired, and all the listeners (included the combobox) get notified. 
When the combobox listener is called, it refreshes the combobox.

Take that recipe, mix it up with some slots/signals jargon, and you get 
first-class event driven witchcraft :-)

Original comment by andresgattinoni on 27 Jan 2011 at 3:14

[GoogleCodeExporter]

Original comment by andresgattinoni on 28 Jan 2011 at 5:39

• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

So, a plugin should have one or more standard pyqtSignal members, which are 
connected by the main window to the right slots.

For example, a plugin could have a bookListChanged signal.

Then, when the plugin *knows* for example, that the book list has changed, it 
calls
boolListChanged.emit() and the main window is notified of the change.

Original comment by roberto.alsina on 3 Feb 2011 at 2:54

[GoogleCodeExporter]

Yep, that's the sort of dark magic I was talking about :-)
I tried to implement what I was saying the other day (without Qt), but I got 
stuck somewhere. How should we implement this?
What I'm thinking now is that in this way we should shove Qt stuff into all (or 
most) of our plugins.

Original comment by andresgattinoni on 3 Feb 2011 at 3:13

[GoogleCodeExporter]

We could avoid that by using some other mechanism, like callbacks.

With callbacks, we would have to pass the main window to the plugins, and the 
plugins call main.updateBookList or whatever.

This would also be useful to make transient dialogs (like warnings or file 
dialogs) have the right parent.

Or we could use adsorb: http://pypi.python.org/pypi/adsorb/0.1

Original comment by roberto.alsina on 3 Feb 2011 at 10:25

[GoogleCodeExporter]

Original comment by roberto.alsina on 13 Feb 2011 at 3:01