[Uml-devel] Re: karbon/umbrello

[Dirk Schönberger]

Luis De la Parra Blum schreibt:

> 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 started a hopefully shared KCanvas class hierarchy in my kpainter project
in KDE CVS.

> 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 

QPoint has only fixed point / integer coordinates
KoPoint and KoRect provide floating point coordinates

> 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.

This was my idea, to. Either that or put it into a separate library which
is only dependent on qt and the render libs like libart.

> 
> 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
> 

Agreed. The pure path approach is fine for a general purpose graphics
editor, but for application specific graphic objects the way is
sub-optimal.

> 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 )
> 

Do you have code available?
Could you please check if it would be possible to work with my code in
kdenonbeta/painter/kcanvas (KDE CVS) instead?

> 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. 

Check. Its KCanvasModel in my class hierarchy

> 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". 

My KCanvasView is just a QScrollView which manages input events and
document rendering.

> 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 

I currently have a separate controller class (KCanvasController), which can
convert view events to documentation specific "high level" events.
I don't really like the current Karbon approach, because this approach
doesn't really allow the use of the KDE xmlgui framework, which allow
already for dynamic configuration of the GUI (menu, toolbar).
I would like to use this xmlgui/kaction framework whenever possible.
You get much better KDE integration by using existing frameworks instead of
implementing your own.
 
> 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.. 

Check. A similar class at my class hierarchy is KCanvasElement.

> 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"
> 

I haven't worked in this direction, my KCanvasElement is only able to
render itself. I am, however fine, to use your definitions into
KCanvasElement.

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

- is not really part of the framework, but rather some helper class
- should consist of segments, where each segment may either be a line
segment or a bezier curve segment. If you need other special segment types,
line horizontal lines or arcs, you could check the KVectorPath class in
kdenonbeta/kpainter/kpainter.


> DiagramWidget: A DiagramElement to which an association can attach itself.
> AssociatonWidget: A Path that can attach itself to two DiagramWidgets. 

Application specific widgets. Should be e.g. part of Umbrello itself.

> 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 )

How about UMLCanvasElement?

> 
> 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

This is real interesting. I know that Canvas like class libraries need back
communication (i.e. from the model back to the view). However, I haven't
seen until now a real implementtation / interface for that. I would be
interested to look at your impl.

> 
> 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.
> 

Do you already render the elements, if so, how?

> 
> ***********
> 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.
> 

Would it be possible to change this sequence so that the standard KAction
framework can be used, instead of a custom framework?

Regards
Dirk