[Uml-devel] Re: karbon/umbrello

[Andrew Sutton]

luis, you're in on this too since you got sucked into the talk :)

> Ok. let me rephrase... ;) What parts of the VObject class library do you
> think are needed most, so that they should be ported to KCanvas?
> I don't think VComposite is the class you look for. Last I checked It could
> only hold VPath, but no general VObjects.
> Maybe you could use VGroup?

everything IS composed of paths. a composite it just (as far as i can tell) a 
set of related paths, whereas a group defines a somewhat "looser" 
conglomeration of paths.

but, the point is - this is for you, luis :) these paths, vobjects (whatever) 
are just object oriented drawing instructions. there's very, very little 
difference between connecting a set of VPaths into a VComposite and having a 
KShape call moveTo(), lineTo() a bunch of times. the VPaths are responsible 
for that. besides, with the VObject stuff, we get transformations!!! 
rotation, scaling, etc.

> I agree. But KPaintDevice was the only way I found which allowed me to
> implement my own paint devices with my own render primitives.
> The way QPainter/QPaintDevice currently is implemented doesn't really
> support such features without hacks.

> KGState (graphics state) implements state management for dumb paint
> devices, which don't have a gstate for themselves.
> Examples for "smart" paint devices, which implement state themselves, would
> be things like a EPS paint device, a SVG paint device, a Xr/Xc paint device
> (XRender extension, which I hope to be able to use somewhen)
> KGState don't necessary have to be in its own .cc/.h file, because it
> really is a helper class.

i'd figured that out by the time i went home last night :) i also figured out 
the right solution - inheritance. simple inheritance. derive 
LibartPaintDevice and QPainterPaintDevice from KPaintDevice (which is derived 
from QPaintDevice). all you have to do is overload the cmd() call on each to 
intercept the appropriate methods. with QPainterPaintDevice, you can just 
"call up" to QPaintDevice. also, you could embed the KGState functionality 
within KPainter to provide state management on demand. i'm going to write all 
this today, it will work :)

> Could you please check if you can work with kpainter/kcanvas in KDE CVS?
> Additions to this lib are very welcome, because there are implemented only
> the most sketchy ideas

i'm going to work out of cvs for a while because i need to sort some stuff 
out. the final version will be structured around the KPainter CVS module so 
it should just be a "drop in".

> I don't think it is really easy to keep KCanvasElements/VObjects
> independent from KCanvas / KPainter.
> At some point the elements have to be rendered, and the rendering API
> defines IMHO rather strong what you can
> do with your elements.
> You could do it the VObject way and implement your own custom rendering API
> on top of a low-level rendering API
> like libart, but I am not sure if this approach is useful.

from KCanvas, it won't be too bad. you're right about the painter though. each 
object does have to render itself. the core VObject stuff WILL be dependent 
on KPainter (or some Painter), but KPainter should be pretty independent of 
the VObject details. it certainly is right now :)

andy