[Uml-devel] Re: karbon14 and uml

[ansutton]

i'm not running linux for the moment or i would have jumped into this 
conversation earlier.

first.. about the whole 2.0 thing. we aren't really targeting 2.0 - we'd like 
to poise ourself to support it when it comes out, but i think the technical 
details will be too great. for example, the metamodel specification stuff is a 
giant component model - not quite the same inheritance model that we know and 
love.

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

second... on the issue of storing svg in xmi documents. most of the graphics 
would be generated by objects according to their attributes and display 
settings - you'd have to save that state information, but you don't really 
need to save the graphics. you'd have to save positioning of objects within a 
diagram, but that's about it - maybe.

i was thinking about graphics provider classes - classes that know how to 
render a certain shape really well - like a UML::Class notation. a new 
provider would be created to represent a UML::Class in a diagram. based on the 
object it represents and its display parameters, it could generate SVG and 
push that off to the diagram, painter or paint device.

i don't really know. i'm still thinking about this :)

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

i think the ideal solution here would be to take the object model from K14 and 
build it ontop of k2d or something that natively supports svg. k14's object 
model has some stuff that it would be nice to take advantage of - specifically 
the connection points and some other stuff.

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

hmmm... i'd still like to use svg as the native rendering format. it would be 
fun ;) what we need is a QCanvasItem that understands how to draw svg.

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

i'll delve into sometime in the next couple days.

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

not really. a graphical notation may or may not reference a UML::* object. for 
example, the use case notation for some use case A would point to the 
underlying use case in the model. we could also put up some other graphical 
things like boxes and text that don't necessarily reference something in the 
model. the diagram itself could maintain the list of graphics providers and 
have them draw themselves or something like that.

saving would just dump the state of the diagram and the graphics providers. we 
could save the svg output of the diagram too - but i don't think we have too. 
the svg would just save the static image of the diagram.

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

i'm starting to think that you may be right. how about this:
- for the time being, we'll sack svg support. when it becomes more stable in 
kde, then we can re-consider the drawing framework.
- until then, we'll use k14's object model and drawing framework. we'll 
probably need to redefine how those objects are saved.
- for psuedo-svg support, when it becomes more stable, we can save each 
diagram in the model as svg. tools could extract the svg diagrams for 
re-rendering elsewhere (like doxygen or kdoc type stuff).

andy