[Uml-devel] Re: karbon14 and uml

[Luis De la Parra Blum]

On Tuesday 08 April 2003 17:08, Sebastian Stein wrote:
>
> Yes. We have a given SVG file and just want to render it. But we would also

it's not "just rendering it"... 
> like to get information when the user interacts with the rendered scene. So
> we need all mouse events like clicking, moving, mouse button and on which
> object.
I wouldnt say we'd like to....we *need* to get this information, and be able 
to manipulate the widgets (or SVGObject or whatever they are called) 
otherwise Umbrello would not be a Modeller.

ok, we'd need to first analyse things.
it's clear that we want to store the diagram info in SVG-format, but that does 
not mean we *must* use that format internally..
as far as I can tell, Karbon14 uses it's own VObjects, which (from a quick 
look at the sources) are much the same as a QCanvasItem, with the difference 
that they dont draw on a QCanvas, but they draw to another device (libart???)

Karbon14 doesnt even use SVG as native storage, but can import and export to 
it (I've never tested it)

If all of the above is true, the only big advantage of using the Karbon 
infrastrucutre over usisng the old vanilla QCanvas is that paths and fonts 
can be antialiased.
I think (and pls. notice that I could be wrong here), we'd need to implement 
our ClassWidget and friends, which must inherit from VObject instead of 
QCanvasItem, but must implement their draw() function just as they do today, 
and must implement their saveToXMI function just as they do today (but this 
time saving our data in SVG instead of some other XML-dialect)


Maybe someone who has looked at Karbon's sources for more than a half an hour 
like me can tell us if I'm right here... if yes, then we'd need to consider 
how much work would be, and if it's worth it to base on Karbon.

the other alternative is using SVG-objects internally... I guess this would be 
much more inefficient, but maybe it has some advantages that outweight that.
For example, in k2d, when you move an object, it seems all they do is to go to 
the DOM and set the attribute "x" and "y" for the corresponding node and 
force a refresh in KSVG.
but we'd still need to create a link between those widgets and our 
UMLObjects.. either by subclassing, or creating a map widget<->umlobject and 
then having a controller or something like that.

I havent looked in detail into either one of the options,but I tend to favor 
the Karbon/QCanvas approach... we would probably not be as flexible as using 
SVG-internally, but I think it'd be much easier to implement, and Karbon or 
QCanvas seem to be more stable than K2d and KSVG.

luis