On Tue, 2003-09-23 at 05:44, Dave Malcolm wrote: > On Mon, 2003-09-22 at 21:41, Bob Smith wrote: > > We're currently discussing what everyone needs in a plugin system. The > > one I'm thinking of is fairly different then whats in GO currently so > > its possible that whats in CVS might change. Could you outline what > > exactly you need in a plugin system and we'll incorporate it into the > > general idea? > > Perhaps the best thing to do is to have a look at what I'm doing > already; the core of the current Conglomerate plugin code can be seen > here: > > http://cvs.gnome.org/bonsai/cvsblame.cgi?file=conglomerate%2Fsrc/cong-plugin.h&rev=&root=/cvs/gnome > Haven't looked at this yet. I will in a bit. > A CongPlugin contains a number of CongFunctionality subclasses; these > are analagous to GOfficePlugin and GOfficeService in libgnomeoffice. > Ok. > I have a CongPluginManager class of which there is a singleton owned by > the application. This is what I was envisioning as well. > > It's all a complete cheat at the moment; everything is statically linked > into the main executable, and not everything is a GObject yet. > > If you look at function "main_load_plugins" here: > http://cvs.gnome.org/bonsai/cvsblame.cgi?file=conglomerate%2Fsrc/main.c&rev=&root=/cvs/gnome > > you'll see how the registration works. > I'll have a look and merge what I can into the design dox. > > The only stuff I share between all services in the CongFunctionality > base class is: > - a human-readable name (translated) > - a human-readable short description (translated) > - a short ID (not translated) > This is on par with the plan. > CongPlugin objects also have a short ID; the idea is that the plugin ID > and the service ID go together to form a GConf path for storing > configuration information. > > For example, the DocBook plugin has ID "docbook", amongst other things > it contains an "Export DocBook as PDF" exporter, with ID > "docbook-PDF-export". > This is interesting. This kind of thing has not been discussed before. Is this suited to being provided stock or in a separate convenience library... How much code is in this? > This means that configuration information for this importer is stored in > GConf in the "/apps/conglomerate/plugins/docbook/docbook-PDF-export" > path, and there's a convenience API for all of this. > > CongPlugin objects (in theory) also have a UI configuration hook, > although I've never implemented this. The idea is that we need a way > for plugins to offer preferences pages to the user. Currently all > per-service configuration is done in a service-specific UI. > This is in the same category as the menu item service. This should be common enough to provide a stock service type in GO for it. > I also need some way of querying for all services of a particular type. > Currently I have a CongPluginManager that has for_each-style methods. Yeah. This is planed. > > Apart from that, and needing to have per-plugin ID strings that can be > used in GConf, the current code in libgnomeoffice looks close to be > usable by me - though not there yet. Yeah. This looks like its very close to what I'm envisioning for things and whats in CVS. One question regarding the ID's. Why do you need them? Why not just hard code them into the plugin? -- Bob Smith <bob thestuff net>
Attachment:
signature.asc
Description: This is a digitally signed message part