Re: Plugin System

[Jody Goldberg <jody gnome org>]

On Wed, Sep 24, 2003 at 05:15:45PM +1000, Martin Sevior wrote:
> 
> My idea is that for every plugin.so, there also exists a plugin.xml.
That is basicly what Gnumeric does now.  With provision that each
directory has a plugin.xml which then specifies the loader
(g_module, python ...) and the loader specific info like which .so
or which source file.

> Upon startup every plugin.xml discovered in the appropriate directory is
> parsed.
That is one of the things currently under debate.  The possibilities
raised to date are

1) Look in various directories at startup.
2) Have an install time application that will search the directories
   and build a list.  This is faster, but more complicated.
3) Look in directories at run time, and cache the result.

(1) is what gnumeric does
(2) seems interesting
(3) is what Bob is advocating, but I'm unconvinced the complexity
buys us anything.

> It's used to create the menu items/toolbars and or information
> that a particular service exists. Plugins do not need to create menu
> items or toolbars and the XML description should allow this.

ick no.
The ability to add actions for menus/toolbars is just one of the
stock services that a plugin can provide implementations of.  We'd
certainly want such an interface, and a common descriptor format.
However, lots of other things can be services

1) GObject type things like
    - import/export plugins
    - loaders for plugins in other languages

2) General application extensions
    - an init routine, and a shutdown routine
      ui extenions would probably be done this way.  However, with
      this would come a notion of a GOApp or something like it so
      that we can share some of the implementation

3) Misc data
    - Useful for listing styles and things that aren't necessary at
      startup, but might be useful later.

> The XML format should specify whether plugin should be immediately
> loaded or whether it can be delayed till later.
Seems like an implementation detail.  The app can decide how it
wants to handle things.

> In the case of additional menu items, the plugin need only be loaded if
> the user clicks on the menu item. The XML file contains the text and
> icons needed for menu/toolbar.
I'd reccomend using the format for the new gtkuimanager (eggmenu).

> In the case of document exporters, the plugin need only be loaded if the
> user asks to export to that format. The XML file contains the filter
> type available for export (so it appears as an option to the user).
I've got a few tweaks I'd like to see in the gnumeric version of
this for things like
    - multiple permissible extensions
    - a default extension

Handling this properly suggests that we'll want some
error/warning/config framework to go with it.

    eg warn that selected format does not support feature 'foo'

> In the case of importers, we may only need to load the "importer
> sniffer" to determine if the document presented matches the importer.
Again there's lots of prior art here.  Gnumeric's implementation
needs clean, and some extension but it is similar.

For both of these services it seems reasonably to define them in
GOffice along with utilites to help manage them.  However, doing
that will start to force the creation of more infrastructure.  Can a
'GODocument' or a 'GOApp' be far behind when drafting there ?

> I think we can come up with a single XML format that is general enough
> for all our uses without placing extra burden on developers to
> understand things they do not need to. Having a single format will help
> translators and hackers moving between the different applications.

A  translation friendly format is of course a requirement, but we
should also support the addition of new service types so that apps
can customize things.