Re: Plugin Management



On Mon, 2003-09-22 at 21:41, Bob Smith wrote:
> We're currently discussing what everyone needs in a plugin system. The
> one I'm thinking of is fairly different then whats in GO currently so
> its possible that whats in CVS might change.  Could you outline what
> exactly you need in a plugin system and we'll incorporate it into the
> general idea?

Perhaps the best thing to do is to have a look at what I'm doing
already; the core of the current Conglomerate plugin code can be seen
here:

http://cvs.gnome.org/bonsai/cvsblame.cgi?file=conglomerate%2Fsrc/cong-plugin.h&rev=&root=/cvs/gnome

A CongPlugin contains a number of CongFunctionality subclasses; these
are analagous to GOfficePlugin and GOfficeService in libgnomeoffice.

I have a CongPluginManager class of which there is a singleton owned by
the application.

It's all a complete cheat at the moment; everything is statically linked
into the main executable, and not everything is a GObject yet.

If you look at function "main_load_plugins" here:
http://cvs.gnome.org/bonsai/cvsblame.cgi?file=conglomerate%2Fsrc/main.c&rev=&root=/cvs/gnome

you'll see how the registration works.


The only stuff I share between all services in the CongFunctionality
base class is:
- a human-readable name (translated)
- a human-readable short description  (translated)
- a short ID (not translated)

CongPlugin objects also have a short ID; the idea is that the plugin ID
and the service ID go together to form a GConf path for storing
configuration information.

For example, the DocBook plugin has ID "docbook", amongst other things
it contains an "Export DocBook as PDF" exporter, with ID
"docbook-PDF-export".

This means that configuration information for this importer is stored in
GConf in the "/apps/conglomerate/plugins/docbook/docbook-PDF-export"
path, and there's a convenience API for all of this.

CongPlugin objects (in theory) also have a UI configuration hook,
although I've never implemented this.  The idea is that we need a way
for plugins to offer preferences pages to the user.  Currently all
per-service configuration is done in a service-specific UI.

I also need some way of querying for all services of a particular type. 
Currently I have a CongPluginManager that has for_each-style methods.

Apart from that, and needing to have per-plugin ID strings that can be
used in GConf, the current code in libgnomeoffice looks close to be
usable by me - though not there yet.

-- 
David Malcolm
www.conglomerate.org




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]