[Uml-devel] Re: karbon14 and uml

[Luis De la Parra Blum]

On Wednesday 09 April 2003 17:36, ansutton wrote:
> i'm not running linux for the moment or i would have jumped into this
> conversation earlier.
>
...
>
> 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.

exactly there lies the difference between using using ClassWidget, derived 
from VObject/QCanvasItem and using some code from k2d ...

*in the first case, we'd have our objects, which can draw themselves to some 
device, and we'd store it's attributes like position and color to the 
diagram.  Note that this is more or less what we have now. of course we'll 
try to clean the design a bit (bye bye WidgetData objects), but the basic 
idea is the same... an object that knows how to render a specific widget 
(classwidgets, actorwidgets, boxwidgets, notewidgets) and save it's state in 
some xml-based format.
In this case you'd need a widget type for each element you need to represent, 
and thats why I think we should have these widgets in a plug in... for 
example:
UMLWidgetSet contains following classes:
 - ClassWidget
 - UseCaseWidget
 - ActorWidget
 - InterfaceWidget
  -PackageWidget
 - ... etc
each one of them "observs" some kind of UML::Element and renders it.
we'd also have a GenericWidgetSet  which would have
 - BoxWidget
 - NoteWidget
 - TextWidget

these things have no UML::Element associated, they are just diagram sugar

if you need to draw a different form, then you'd need to extend a widget set 
or create a new set and plug it into umbrello

*** In the second case, we would not have  ClassWidgets or BoxWidgets.. we'd 
just have a "SVGRenderer" which would take a dom-node, containing a fragment 
of a parsed svg-file and render it... it'd be the same renderer that renders 
a class, a box, a line an actor or wahterver... since all svg shapes are 
based on some primitives, you could render whatever shape you want without 
having to modify your code at all....but then you would not have an object 
behind the image you see on your screen. what you see there would be nothing 
mor than a picture, just like a gif or jpeg...
when you click on the diagram, you need to get the position, walk the DOM tree 
to see which node would collide with the position when rendered, look what 
object it's supposed to represent.
Also, when you add an attribute to a class, for example, you'd need to  walk 
the dom, find the node rendering it, make it's height a bit higher, and add 
another <text>attname</text> element to the node.

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

exactly what I'm talking about.. that corresponds to 1)

>it could generate SVG
> and push that off to the diagram, painter or paint device.

of course it could export to SVG, and it could even store it's own attributes 
in SVG and read them from there, but it can only support a (very small) 
subset of SVG.. I mean, it would know how to draw itself, but it could not 
draw any arbirary shape based on a SVG document.

> 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

like I said, I dont know the details of either one, but I think the two of 
them are not mixable.
in k14 you have vobjects, and in k2d/ksvg I would suppose you have a 
"svg-renderer" that knows how to render lines, boxes and all other 
svg-primitives, and how to recurse groups

> object model has some stuff that it would be nice to take advantage of -
> specifically the connection points and some other stuff.
I think antialiasing would be the big one. I dont consider the connection 
stuff so important/difficult to implement on whatever code we decide to go 
with

>
> 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.
>
be careful here... you mean you'd like to save/read SVG, or that you'd really 
like to be able to render any SVG code? 
in the first case you'd have something like
<shape uml_object_if="12" color="yellow" show_atts="yes" show_ops="no" />

and that's it.. the ClassWidget reads it's attributes/setup from the document, 
and it knows how to render the class.
in the second case, it means that I could have something like
<shape uml_object_id="12">
<>tags here to draw a tea-pot</>
</shape>
and you would  draw a uml::class as a tea pot. that is, the renderer doesnt 
know what it's drawing, it just follows the instructions found in the file

> 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

yes. but a "WidgetClass" always draws a UML::Class, and a UseCaseWidget always 
draws a UML::UseCase, and a BoxWidget knows nothing about UML or other 
metamodels

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

ok, so it seems clear now.
the only problem is that the guys at omg want to "standarize" the way you dump 
the state to the file... if you only have to dump the attributes like 
position and color, then it's ok, but the thing that's bothering me is that 
they were talking about using svg for storing information.... and if they 
dont use only a small subset of it, but really save the shape to the diagram 
( line from point x to y, line from y to w, line from a to b, text "abc" at 
position w) then we'd be in trouble

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

no, I think we can support a subset of svg, but I dont think we can (as of 
now) associate any free-style shape to an uml::class

> - until then, we'll use k14's object model and drawing framework. we'll
> probably need to redefine how those objects are saved.
yes. since k14 is a drawing program, it must be able to render any shape, and 
I guess they store the most complex things as a collection of primitives like 
lines and boxes.
in our case the primitives would be more elaborate ( we'd have classwidgets 
and usecasewidgets as "primitives" ) and we'd store a diagram as a collection 
of them (classwidget at pos x,y in red  ,  interfacewidget at pos z,x in blue 
)


luis