Re: libgnomeoffice* plugin management

[Rodrigo Moya <rodrigo gnome-db org>]

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
> 
I can do a release whenever you want.

> 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.
> 
right, this needs to be added

> 3. There seems to be no definition of a plugin search path but the path
> for xml definitions seems to be hardcoded
> 
yes, I was planning to even add API calls to add new directories to
search for plugins, so yes, another thing that needs to be done.

>   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.
> 
well, for the data service API, instead of rewriting a lot of stuff, and
since most GNOME Office applications depend on libgda, I didn't think it
was a too heavy dependency. Of course, if we had the tree model stuff in
glib, we would't even need to depend on libgda, since libgda would use
those data models instead of their own, as it does today

> 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.
> 
yes

>   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.
> 
there is none :(

If you really want to put some work on it, I'd be glad to help you
-- 
Rodrigo Moya <rodrigo gnome-db org>