[Uml-devel] Re: karbon/umbrello

[Luis De la Parra Blum]

hi all,

On Monday 12 May 2003 15:39, Andrew Sutton wrote:
> okay... i'm starting to get a better picture of our proposed general
> purpose vector drawing lib. we have 3 parts to it:
> - the painter
> - the canvas/document
> - the path core

I've bee trying to follow this thread.
some days ago I started a new diagramming code for Umbrello 1 (current 
version) in the hope of solving some problems which would be very difficult 
to fix in the current code.
I took a (quick) look at Karbon, and I really liked the idea behind it, but 
could not use it as a base because of the KoPoint Vs. QPoint conflicts, not 
so easy integration/dependencies as QCanvas, etc, so I think it'd be great to 
move those for now KOffice specifics which are not really KO speciffic to 
some kdelib.

The other reason I couldnt / didnt want to take Karbon's code as base, is that 
it seems to draw everything as a collection of paths ( vectors ). That is, a 
box is nothing more that four paths put together in some kind of container...
this of course offers the most flexibility but for umbrello I thought it'd be 
easier to have more specialized objects that just paths, so instead of having 
a bunch of lines and texts for a UML::Class, I wanted a UMLClassShape which 
is specialized on drawing that kind of objects

So, to make it short, for those two reasons I could not take Karbon's code as 
base, and I wrote everything from scratch, but the code is somewhat inspired 
in Karbon's ( Tools, Shapes, Views )

I've put two overview-diagrams (as png's) at Umbrello's site, in case someone 
is intereseted  ( of course you can also have the code. it's under 
umbrello/diagram and umbrello/plugins/umlwidgets

the code is (more or less) well documented, but here a small description so 
that you understand the diagrams:

Diagram : this is the "document" -- not really a document, but it contains / 
manages the objects. in the case of Umbrello it's  a part of our Document. 
Note that this is not a visible object, you look at the diagram through the 
DiagramView (one or more views can be attaches to a Diagram)

DiagramView: Renders the Diagram and allows user interaction. It has a ToolBar 
with a bunch of "Tools". When it receives events (key, click) it passes the 
events to the tools, and they decide what to do with them. The view knows 
pretty much nothing about the tools or the shapes it's rendering. The tools 
are loade via ToolBar::addTool( string ), so the tools available for a 
diagram could even be loadef from a confing file, and the only shape it knows 
it's DiagramElement.. all other interaction is handled by the tools

DiagramElement: Base class for all elements in a diagram ( I guess this would 
be your VObject) - offers basic functionality like move, setSelected and 
"executeDefaultAction"

Path: A collection of lines ( or a multi-segment line, if you will )

DiagramWidget: A DiagramElement to which an association can attach itself.
AssociatonWidget: A Path that can attach itself to two DiagramWidgets. When 
they move, the Association adjusts its ending points or completly move along 
with them

** the real shapes are implemented in plugins, right now I have
plugin umlwidgets
(replace the word Widget with Shape if you prefere so, UMLWidget->UMLShape )

UMLWidget: a DiagramWidget which represents an UML::Element in a diagram. When 
it detects that the UML::Element has changed, foreces a recalculation/refresh 
of the widget

UMLClassWidget: draws a UMLClass on a diagram
UMLAssociaitonWidget: like an associationwidget, but it represents a 
UMLAssociation ( the normal AssociationWidget has no UML-meaing, it's only a 
visual thing)
(the same for other UML::Elements)

plugin generic shapes /tools
Shapes like Notes, Boxes, TextLines, etc.


***********
All shapes are created by the corresponding Tool, or they can be created by 
the diagram through a WidgetFactory if they are droped into it ( for example, 
if you want to create a new UML::Class, you use the ClassTool -> when you 
click it creates a Class, and then a widget to represent it. But if you drag 
an already exisitng UMLClass into the diagrm, the diagram calls 
WidgetFactory::createWidget( object ), then the WidgetFactory quries all 
loaded plugins to see if one of them can handle that kind of object, and if 
yes, the plugin creates the widget and returns it.


you may find the diagrams at:
http://uml.sourceforge.net/developers/umbrello-diagram-overview.png
http://uml.sourceforge.net/developers/umbrello-shapes-plugins.png

regards,

luis