[Gazpacho] Plugin system proposal

[Johan Dahlin]

> What's the difference between a widget library and a plugin

> Unfortunately right now widget library are somewhere called plugins and
> it makes this classification not obvious.

Hopefully we can convert the libraries to be plugins in the future, so we
don't need to have separate infrastructure for both.

> Anatomy of a plugin

> * A __init__.py file. Otherwise it won't be a Python package. In this
> file,
>   the plugin metadata is located in the form of the following variables:

I'm not sure if this kind of metadata should live in the source code, I
think it's better to let it be in an .ini file so we don't have to
load any python code to fetch information about a plugin.
Check how gedit does this.

> * A plugin.py file where a subclass of gazpacho.plugin.Plugin should
>   be defined. The name of this class should be the same as the string
>   'plugin_class' found in the __init__.py file

just use namedAny to fetch the python object, it can then be a package or
a module.

> Plugin Manager
> --------------
> The Plugin Manager is instantiated by Gazpacho at start up time and it
> loads all the plugins. This mean that it maintains a list of PluginInfo
> objects. Each PluginInfo object has meta information about the plugin
> such as:
> 
>    - Plugin Id

Name is probably better here.

>    - Plugin module
>    - Plugin class name

It seems to me that you don't need both of these.

Version too perhaps?

> Plugin base class (gazpacho.plugin.Plugin)

> class GazpachoPlugin(object):
> 
>   def get_ui(self):
>     """Returns the UI string for this plugin"""
> 
>   def get_actions(self):
>     """Returns a list of actions that match the UI string definition"""
> 
>   def on_object_selected(self):
>     """This will be called every time an object/widget is selected"""
> 
>   def on_project_changed(self):
>     """This will be called when a project is opened or selected"""

You don't need any of these, instead pass in the application object and let
the plugin developer fetch projects/selections/whatever themselves.
They would also be responsible for merging/removing actions and xml from the
 ui manager. Leave as much freedom to the plugin writers as possible.

If we want a stable plugin api we provide a wrappers for all objects.
It includes signals/properties/methods.

Things necessary to support:
* Application
  get toplevel gtk.Window
  get ui manager
  get current project
  listen to project changes
  get command manager

* Project
  ???

* Command manager
  undo
  redo
  execute

It'll be a bit of extra work, but I think it'll pay off to do this.
The wrappers are going to be very simple and can probably live in
plugin.py.
The plugin writers can still access private variables such as _project,
traverse children on the toplevel window etc, but without the API stability
guarantees.

Looks pretty good otherwise, it's on the right track

-- 
Johan Dahlin <jdahlin at async.com.br>
Async Open Source