[Uml-devel] Re: karbon/umbrello

[Andrew Sutton]

> - are you really sure about using VObject directly? Please see my last mail
> about this.

absolutely. there's alot of stuff there for building composite objects that i 
don't particularly feel like trying to rewrite. i like the groups and such. 
its got some good memory management stuff built in too. subclassing that 
stuff a VComposite as UML::ClassBoxNotation or UML::UseCaseNotation would be 
pretty easy (and fun for the kids ;)

anyways, i'm getting way into the guts of both KPainter and VPainter and 
finding some really, really weird stuff that i'm having trouble explaining. 
for example, how complete is the QPainterPaintDevice? it doesn't actually 
seem to do anything besides push drawing commands on on the KGState (what 
does that stand for?). LibartPaintDevice seems a little more complete, but i 
haven't gone through it completely. the KPaintDevice is just a total hack - 
there's got to be a better way to write that. also, the entire KGState thing 
is kind of sketchy. it might be a little bit overkill. if you encapsulate 
state management inside KPaintDevice, and then delegate calls out to the 
"real" paint devices, it will look alot nicer.

then, looking at VPainter, i see that it's not making any attempt to follow 
the QPaintDevice abstraction. the painter just draws uses libart directly - 
not that its bad, particularly, but it could have been written down 
somewhere.

i think i'm going to end up pulling these two pieces of code completely apart 
and rebuilding them from the ground up.

> - KVectorPath was just a test. Primarily I wanted to define a rendering
> model which was even more SVG oriented than the current element, especially
> I would like to provide the SVG path composing operators, like
> relativeLineTo, as part of the KPainter API. This idea proved to be
> impossible, at least with my rather limited
> knowledge of ector mathematics. So currently KVectorPath is some kind of
> artefact. Perhaps it should be renamed, like to KSVGPath, and put into the
> lib handling more SVG oriented, like kpainter/svgutils.

actually, now that i think about it, is the KGState stuff even necessary if i 
use VObjects? i might just be thinking this because i'm not sure what KGState 
is really doing. but if i'm not too far off it seems like it would be 
duplicating the object model used to create the segments. it might turn out 
to be extraneous code.

> Why you want to use KCanvasElement as wrapper of KShape instead of
> inheriting it?

its all about separation of concerns. the canvas element is essentially a 
visualization structure thats used to tie the KShape/VObject stuff to a 
specific instance of a view. all of these VObjects or KShapes should be able 
to be drawn independently of any view - or any paint device. by forcing all 
the visual structures to be derived from KCanvasElement, we'd essentially be 
saying, "you MUST use KCanvas" and some people might not want that. we should 
be able to put this stuff on other views too.

> I'm looking forward to it ;)

so am i ;)

andy