[Uml-devel] new u2 stuff

[Andrew Sutton]

man, i really screwed the pooch on configuration management today :) the build 
should be "stable" right now though. at least its compiling...

anyway, what i've done:

- basically rewrote the entire plugin system to use KPart::Plugins. this 
includes fun stuff like installing ui.rc files for each plugin in 
apps/umbrello2/kpartplugins.
- rewrote the umbrello2 application to use a KPart::ReadWritePart to house the 
main view (which is currently just an empty KListView as a place holder). i 
figure we can plug other views (like diagrams into that).
- finished the uber-generic XMI parser. it will now correctly parse the xmi 
files that define metamodels and establish the meta-object relations between 
the created objects and the code that implements them. its actually pretty 
sly. i'm very happy with it.

that's the good stuff. here's the bad stuff:
- completely broke the plugin loading protocol.
- crippled any functionality that i had already achieved

that's about it, but it should be back on line tomorrow. because the plugins 
are now loaded automatically, it doesn't make sense to keep using the plugin 
loader to load meta models on demand. if they're exist in the kparplugins dir 
for umbrello2, they're going to be loaded anyway - although they're just 
going to add stuff to the menu or the toolbar - maybe.

what i need to do tomorrow is re-define the loading protocol and just make it 
an initialization protocol. in other words, when the application starts up, 
look at the plugins that are in the umbrello2rc file (or whatever rc file) 
and call "init" on them. we can't guarantee the order of that KParts loads 
plugins, but we can use the old loading framework to control the order in 
which they're initialized. this will, for example control the loading of MOF 
before the loading of UML - and it provides the opportunity to parse the xmi 
files.

for the rest of the gui - here's what i'm thinking. we can continue using 
plugins to load by default. by controlling the initialization of the plugins 
(not the loading), we can have plugins create KParts that provide views that 
can be integrated into the application. or, we can have kparts that load 
other kparts. essentially, its a massive chain of loading shared libraries. 
sometime soon, i'm going to start work on the model view - the list view from 
1.x - only i'm going to build it as a kpart that's loaded and set as a 
default view by the umbrello2 kpart (libu2_umbrello2 - not to be confused 
with libumbrello2 which is the core library). i can use this view to register 
action collections defined by various metamodels. for example, there's going 
to be an enormous action collection supported by UML. those would all be 
registered in various forms with the model view to do fun things like create 
packages, classes, stereotypes, use cases - whatever.

so, hopefully by this weekend i'll have completed the rewrite of the load 
protocol and been able to bring the old functionality back online in addition 
to some other goodies, like a UML menu that's added by the UML metamodel 
plugin and supports fun things like a stereotype definition menu.

thoughts?

andy