[Uml-devel] Back - big changes/more instability

[Luis De la Parra Blum]

Hi all,
well.. I had to leave all of the sudden and didnt touch a computer for the 
last two weeks,  so I'm not really aware of what's been happening around here 
for a while. I just got back and still have over 200 mails to read, alone 
from this list.

before I left I was working on some big changes to my diagram stuff. I 
actually wanted to commit them before leaving, but I had almost no time to 
prepare my trip and could not commit anything.

so, what are the changes?
the Umbrello::Diagram class did not change much, but most of DiagramView and 
the widgets has changed.. it is now inspired on the Karbon14 code:

- The view doesnt do anything now, but delegates the handling of mouseclicks 
and keys event to the "Tool" s . this is a much much cleaner design since 
alows each tool to just handle it's part instead of having *huge* swithces/ 
if.elses blocks in the diagram/view

- I tried to make things in such a way, that it should be easy to use a 
different Model Object, like for example, the code from U2 - that means the 
diagram part is (still) pretty loose(?) coupled to the "model" code.

- Altough I know Andy wants to use Karbon14 code for U2, and one of my goals 
with this is to maybe allow a "transition" from U1 to U2 I did not take any 
code from Karbon14, but only inspired myself on it - some of the reasons I 
did not take their code are:
 - their "tools" seem to really "draw" thier shapes on the device, while in my 
code, the "tools" only create the shapes, which in turn draw themselves. the 
reason for that is that we are not writing a generic drawing program, but a 
modeller, so we dont need "as much" drawing-flexibility as in a "free-style 
draw" capabilities, and  we need a connection between the shapes and the 
underlying model.
 another reason I didnt take Karbon's code is that they seem to use KPoints, 
KPainters, and so on, while I decided to go for QPoints and QCanvas for now, 
to make the integration with U1 easier - I think KPainter has an api similar 
to QPainter, so maybe things can be ported in case we do decide to go that 
way for U2

ok - so now about the new code..
I have a small class diagram of the new design- maybe I can add some comments 
to it and publish it in case someone is interested.

only the basic classes are now part of the "main program" ( the base classes 
for all shapes, plus a generic path/association shape and the "selection" 
tool), all UML-specific shapes are now in a plugin which can be 
developed/improved/changed without touching Umbrello itself. the plugin is 
for now called "libumlwidgets"

For now libumlwidgets only has implemented the UML::Class widget, but doing 
Interfaces and Packages should be a 15 min. copy and paste thing. doing
There is also a "generic association" built into umbrello, and doing 
"UML-specific" associations ( Generalization, Composition ) shouldn't be too 
difficult either ( head/tail shapes are missing, plus labels for roles and 
multiplicity )

so I guess the rest of the shapes for all other UML::Objects in umbrello can 
be implemented in a relatively short time. anyways, I did code a 
"UnknownUMLWidget" class, which is never supposed to be seen in action, but 
it's meant to show you a widget for all objects in a diagram in case the 
uml-shapes plugin is not found or not fully implemented ( for example, you 
now get a Class widget for UML::Class objects, but you get an "Unknown" 
widget for Interfaces and Actors, because those are not yet implemented by 
the plugin.

You can of course have more than one plugins active at the same time, so I'm 
thinking of having two for U1 ( uml-shapes, and "generic"-shapes containing 
boxes, and notes ) - for U2 we could have one/more plugins for each metamodel 
we have.

The new code solves some problems which seemed "impossible" with the old code, 
for example, the placing of the associations- in the new code you can set an 
association to "auto adjust" (like current U1 code) or to "stay fixed to a 
point" and then manually place it wherever you want,

.. but more details on that after I commit the code. first I have to sync my 
copy, resolve any possible conflicts due to changes in the repository in the 
last two weeks, go out for a beer or two, drink one more beer (hey, it's 
friday) and hopefully tomorrow I'll commit the changes to the repository and 
publish the nuew uwdk (containint libumlwidgets)- since I guess noone is 
really using/working on the new diagram code, I guess no one should have a 
problem with me commiting such changes.. you will probably not even notice 
it, but anyways, email me before tomorrow if there's a problem with it.

regards,

luis

ps. in case andy is reading this: I called everything *Widget (like 
ClassWidget, ActorWidget) because 1) that's what they are called in U1, and 
2) I had started with that code before knowing you dont like that name
-- anyways, I guess the name could be changed to "ClassShape" or 
"ClassGraphic" or whatever... maybe Diagram::Class  for representing a 
UML::Class and so on??