On Thu, 2003-09-25 at 13:39, Jody Goldberg wrote: > On Thu, Sep 25, 2003 at 01:24:14PM -0700, Bob Smith wrote: > > Some states a plugin could be in: > > > > Enabled > > Disabled > > I would keep these distinct from > > > Another set: > > > > Unloaded, > > Loaded, > > Unloading > > > > One more: > > > > Unloadable > > These. > Yeah. I was thinking having say, an enabled unloaded plugin or a disabled unloading plugin. > > Maybe we should have an Unloadable flag for glueins, or for plugins > > that can't be unloaded once loaded (gmodule can do this, right?). But, > > something unloadable can be hidden from the app by not being able to > > query for it, so we still can disable them. > > The simple solution would be a virtual : > GOService::unloadable_p > A plugin is unloadable if all of its services are. > Well, This might be good, but usually a plugin is unloadable as a whole. Some systems can dynamically load but then cant unload a .so file. I cant think of a specific instance of a service that cant be unloaded but a plugin can. > An interesting design to consider for the future is to support in > place reloads. This is very useful for rapid application design, > but is probably somewhat unique to spreadsheets. The goal being to > allow a user to remove and reconnect a new version of a plugin > without restarting. This is interesting. As I understand it, you would have to use a proxy object correct? Are you talking about reloading a plugin where the application doesn't know the plugin was ever removed? > _______________________________________________ > gnome-office-list mailing list > gnome-office-list gnome org > http://mail.gnome.org/mailman/listinfo/gnome-office-list -- Bob Smith <bob thestuff net>
Attachment:
signature.asc
Description: This is a digitally signed message part