Re: Plugin changes
- From: Dave Malcolm <david davemalcolm demon co uk>
- To: Rodrigo Moya <rodrigo gnome-db org>
- Cc: Conglomerate Development <conglomerate-devel lists copyleft no>, GNOME Office List <gnome-office-list mail gnome org>
- Subject: Re: Plugin changes
- Date: 13 Jan 2004 16:24:27 +0000
On Mon, 2004-01-12 at 12:21, Rodrigo Moya wrote:
> On Sun, 2004-01-11 at 04:56 +0000, Dave Malcolm wrote:
> > I've done a big rewrite of Conglomerate's "plugin" code.
> > My hope is to eventually use the libgnomeoffice plugin framework, I aim
> > for this to happen for our 1.0.0 release, rather than for 0.8.0.
> > Conglomerate's internal plugin API is now very similar to that of
> > libgnomeoffice (in Gnome's CVS), so it should now be easy for us to
> > start using that, in theory anyway.
> cool! Don't you need any addition/change to current libgnomeoffice in
Possibly. Difficult to say until we actually try to use the code, which
as I said isn't slated to happen for a while. I'm sure that once we
start using the code for real we'll find a few problems here and there,
but we'll deal with them as they arise, I suppose.
Once Conglomerate's 0.8.0 release is out of the way (and unfortunately
there are some major, difficult bugs to be fixed before that), I plan to
add libgnomeoffice into Conglomerate in a "copy-and-paste-code"
subdirectory, similar to how Gnumeric seems to be managing its
bleeding-edge dependencies. Any changes we need will, I hope, be minor
and can go back upstream to the main CVS version.
Currently we're cheating: all Conglomerate "plugins" are actually
"glue-ins" - they're statically linked into the main executable. A
function called near the start of main calls all the registration hooks
for the various pseudo-plugins.
There's a CongPluginManager class which approximates the
GOfficePluginLoader in that it manages CongPlugin objects which in turn
manage CongService objects.
The registration hook for a plugin is passed a CongPlugin as its
interface to the plugin system, it registers various CongService objects
into the plugin.
There aren't any XML service description files as yet.
My plan is to make CongService be a subclass of GOfficeService. Our
services are almost the same as GOfficeService but add ID codes to allow
references to them to be stored in our data files. CongPlugin would
probably be replaced by GOfficePlugin.
GOfficePluginLoader would probably replace CongPluginManager. I'd
probably add a goffice_plugin_loader_for_each_service_of_type hook, to
complement the method which makes a GList, with an early-exit.
Plenty of bugs to fix for 0.8 before all of this, alas :-(
] [Thread Prev