Re: libgnomeoffice* status



On Thu, 2003-09-18 at 11:13, Rodrigo Moya wrote:
> Hi
> 
> Ok, so here's the current status of the gnome-office module:
> 
> * libgnomeoffice: non-UI stuff, currently contains:
> 	- go-plugin-loader: class for client apps to load plugins
> 	- go-plugin: base class to be implemented by plugins
> 	- go-service: base class for services (each plugin implements
> 	  'n' services)
> 	- go-service-data: data acquisition service (SELECT .. FROM)
> 	- go-service-file-io: services for file i/o operations
> 	- go-service-function-group: service that implements a
> 	  group of callable functions
> 	- go-service-script-engine: scripting service
> 
> * libgnomeofficeui: UI-stuff
> 	- go-plugin-manager-dialog: this is just the beginning of
> 	  a dialog for managing the plugins, similar to the one in
> 	  Gnumeric, but to be shared by all apps. I didnt work too
> 	  much on it because I prefered to wait post-1.0.
> 
> * plugins: built-in plugins
> 	- database: contains an implementation of the data service,
> 	  based on libgda
> 	- scripting: will contain implementations of the scripting
> 	  service for various languages. Right now, there is basic
> 	  support for Mono.
> 
> So, what are the thoughts on this and on new things to be added? As Jody
> said, I think it's better to see case by case when the issue arises,
> but, for the plugin system, we are going to have to share a lot of code,
> given that abiword and gnumeric and mergeant already have, each one,
> their own plugin system. So it is the most important thing right now,
> IMO.
> 


> So, do we go on on sharing the plugin system?

This code looks useful to Conglomerate, and I'm going to have a look at
using it.  Currently our plugin system is a complete fake; everything is
simply linked in, but done using service registration hooks.  The "go"
system seems to be analagous to what I had in mind.

Some questions:
(i) I take it that the idea is that I subclass GOfficeService as
necessary for my own app-specific plugins?
(ii) Are we looking to share plugins themselves, as well as the plugin
system?  i.e. 
	(a) there are GOfficeService subclasses that are "publicly" available
as part of the system (such as the examples listed above), and
	(b) there are plugins that exist in one shared place to be locatable by
all Gnome Office apps, that provide instances of those services.  Could
lead us to DLL hell...
(iii)  Should I add the gnome-office module as an external dependency,
or should I create a cut-n-paste code subdirectory within my source
tree, and synchronise on a regular basis?
(iv) Similarly, should I add libgsf as an external dependency, or
internally as a cut-n-paste dependency?

Dave





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]