Re: libgnomeoffice* plugin management

[Jody Goldberg <jody gnome org>]

On Tue, Jan 18, 2005 at 01:31:29AM +0100, Rodrigo Moya wrote:
> On Thu, 2005-01-13 at 12:25 +0100, Sven Herzberg wrote:
> > Am Donnerstag, den 13.01.2005, 11:32 +0100 schrieb Jean Bréfort:
> > > 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.
> > 
> > http://cvs.gnome.org/viewcvs/criawips/src/cut-n-paste/goffice/
> > 
> > > libgoffice has plugin support and also a charting engine that might be
> > > used in criawips/
> > 
> > It hasn't you can try to find it at [1] but you will fail. You will find
> > it in Gnumeric's tree [2].
> > 
> > [1] http://cvs.gnome.org/viewcvs/gnumeric/src/cut-n-paste-code/goffice/
> > [2] http://cvs.gnome.org/viewcvs/gnumeric/src/ (see plugin*.[ch])
> > 
> > I don't think that just copying and pasting will be enough, as different
> > developers expect different features; e.g. I'd like to see things like a
> > FileFormatService that specifies mime types that it can read; other
> > people might want to have specified whether plugins can be loaded at
> > runtime or whether they need to be loaded at startup. The plugin system
> > of Gnumeric is e.g. not based on interfaces and so I'd like to design a
> > new/modified plugin system.
> > 
> > To make it usable for most of us, we need to discuss what we need and
> > what we don't need, so there won't be neccessary major changes within
> > the near future (as requirements may change I don't talk about 2 or 3
> > year scopes).
> > 
> IMO, the basic things we need are: a plugin loader, a plugin class and
> generic interfaces for "services". I think what there is in
> libgnomeoffice is a good base for that.

The plan is to get the code out of Gnumeric and into a stand-alone
library before GUADEC 2006.   99% of the work is now in CVS and
Gnumeric is using it.  I've borrowed liberally from libgnomeoffice
in some of the transition and will pull in more when the split is
complete.

The library is starting to take shape as
    - non-gui utils and extensions to (libxml, libgsf, glib)
    - gui extensions (various combos and GtkActions, gradient
      selectors etc)
    - The plugin system from gnumeric/libgnomeoffice
	: This works, but is in transition cleaning things up
	: It will include an Python loader as a plugin
    - The interface (aka service) definitions from gnumeric that are
      generally applicable.
	: Plugin Loader
	: Import/Export interfaces AND the ui/infrastruction to go
	  with them (progress monitors, remote loading, encryption,
	  warning handling, cmd line options, configuration)
    - The number formating engine from gnumeric
    - The charting engine from gnumeric
Things that will not be ready
    - '--without-gtk' or a libgoffice-gtk
      People are working on this, but it will not block the split.
    - Gnumeric's 'SheetObject' (an embedded object definition)
      This is hard, and we just don't have enough time or bodies to
      work on the next generation.  Some of it will happen as part
      of gnome-presentation-viewer's sharing of gnumeric's escher
      importer.

That last one seems a bit questionable as part of libgoffice proper.
When we're do the CVS surgery to move things into their own module
there should be some discussion.

We're down to about 10-20 warnings of calls from libgoffice up into
gnumeric.  When that is finished (hopefully next with when I'm in
Boston) I'd like to start soliciting input on the next steps.