[Uml-devel] Re: u2 plugins

[Andrew Sutton]

On Tuesday 11 March 2003 3:13 pm, Luis De la Parra Blum wrote:
> On Tuesday 11 March 2003 20:05, Brian Thomas wrote:
> > 	I think you should drop the "U" from the name of the umbrello classes.
> > They should just be "application", "configurable", "plugin" and "tool".
> > You can always supply the "umbrello" package name to the class in order
> > to distinguish it properly (e.g. "umbrello::application".
>
> I also think you sould drop the U and make them Umbrello::Application and
> Umbrello::Plugin instead.
> that way you dont have name conflicts, and you can always use the
> namespace, certain classes or an alias so you dont have to write the whole
> thing if you dont want to

well... there's an Umbrello namespace now... and some classes. i've made a 
slight misjudgement in my thinking about plugins. the design needs to be a 
little more complicated... i can imagine for example, that all plugins 
created via KLibFactory are singletons. the way the code is written now, 
plugin initialization and shutdown code is executed every time a plugin is 
loaded.

as a side question. would there ever be a case where we'd want to create 
multiple instances of a plugin? i don't think so, but i can't think of 
everything.

we could solve the singleton by building plugins as a more solid abstraction 
on top of shared libraries (it's a pretty weak abstraction right now). We's 
have a plugin loader to replace the library loader (guess what it does?) 
because it sits on top of the libloader, it removes the job of handling 
multiple loads from the libloader. it would also have to re-implement 
reference counting. yeah.

now, i've made some mistakes in my implementation as well.. if i read the docs 
right, libraries are automatically unloaded when the last object created from 
it is deleted. so i could build the refcount into the plugin. each 
plugin->unload() decrements the refcount, finally deleting the object. the 
plugin loader would have to be connected to the destroyed signal of QObject 
for it in order to remove it from its mapping. the plugin finally being 
destroyed (and only created once), the lib loader should automatically 
release the library.

sound right?