Re: libgnomeoffice* plugin management
David Malcolm <[email protected]> Wed, 12 Jan 2005 19:15:10 -0500
| Newsgroups | gmane.comp.gnome.office.general |
|---|---|
| Message-ID | <[email protected]> |
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