Re: Plugin Management
- From: Dave Malcolm <david davemalcolm demon co uk>
- To: Bob Smith <bob thestuff net>
- Cc: GNOME Office List <gnome-office-list mail gnome org>
- Subject: Re: Plugin Management
- Date: 23 Sep 2003 12:44:57 +0000
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]