Re: libgnomeoffice* plugin management

[Jean Bréfort <jean brefort normalesup org>]

Le mercredi 12 janvier 2005 �9:15 -0500, David Malcolm a �it :
> On Thu, 2005-01-13 at 01:11 +0100, Sven Herzberg wrote:
> > Hi,
> > 
> >   I'm currently looking for plugin system that I can use for my
> > presentation application [1]. I took a look at the libgnomeoffice plugin
> > system [2] which looks quite nice for me. I had some objections and just
> > want to keep them here for discussion, so flame me:
> > 
> > 1. There hasn't been any release (thus making it hard to add even a
> > versioned dependency)
> > 
> >   not hard to fix
> > 
> > 2. Plugin definitions are not translatable
> > 
> >   we should include translation for plugin description in the XML file
> > (like we do with GConf schemas) so the library can provide a
> > translation.
> > 
> > 3. There seems to be no definition of a plugin search path but the path
> > for xml definitions seems to be hardcoded
> > 
> >   This makes it quite hard to keep clean systems like /usr being only
> > for distribution stuff. I'd like to have a small configuration file (or
> > GConf key) so admins/users can specify paths for themselves. The GConf
> > solution would make it very easy to have an admin specifying some sane
> > defaults and some users can overwrite it for themselves (e.g. I can use
> > different plugins as different users, stable ones when showing
> > presentations, unstable ones when developing)
> > 
> > 4. It depends on libgda
> > 
> >   Unfortunately not every application will need to depend on GDA. Read
> > more in the next section.
> > 
> > 5. The project's structure seems to be a bit blocking
> > 
> >   I think that services should be specified as GInterfaces that can be
> > implemented by my own code, so I cannot run into a case when I want to
> > subclass one of my classes to implement a service.
> > 
> >   Services might be provided as loadable plugins as well, so we end up
> > with one base service and all other ones deriving from them. This makes
> > it easy to let interfaces depend on other ones. This way we can depend
> > on GDA optionally to provide the DataService and applications that build
> > plugins can check for this module at compile time (enabling a small
> > build for developers and good module splitting for distributors).
> > 
> > Regards,
> >   Sven
> > 
> > [1] http://www.nongnu.org/criawips
> > [2] http://cvs.gnome.org/viewcvs/gnome-office
> > 
> > PS: Does anyone here know projects that already use libgnomeoffice? I
> > don't think there are any as Malcom was mentioning it for conglomerate,
> > but configure.in doesn't mention it.
> 
> I've reorganised Conglomerate's plugin API to correspond closely to the
> one used in libgnomeoffice, but we don't actually use it yet.  I plan to
> do so once libgnomeoffice is readily available in the popular
> distributions.
> 
> (Conglomerate doesn't _actually_ have plugins yet; they're still all
> compiled into the main executable; they do go through a plugin-style
> registration/discovery interface, though)
> 
> (Have been a bit busy with other stuff, alas)
> 
> Dave Malcolm

You should also have a look at libgoffice. It is still not independant
from gnumeric but it will happen hopefully soon. Jody might tell you
more about the delay.
libgoffice has plugin support and also a charting engine that might be
used in criawips/

Regards,
Jean