[Uml-devel] Re: karbon/umbrello

[Dirk Schönberger]

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

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?

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

Not really. Somehow the most interesting functionality is in renderPath, and
render path is a render primitive, which can be parametrized (how the path
is to be rendered, which pattern or gradient is to be used).
I agree that most other parts of a QPaintDevice just putting things to the
GState.
I did this because I somewhen want to implement a Postscript generator
paintdevice, where I want to express things like "setcolor", "setlinewidth"
and such directly, i.e. a KPainter call generates the appropriate Postscript
call.
renderPath was added because there were some requests for optimized
rendering, i.e. filling and stroking paths without having to resort to the
gstate.

> the KPaintDevice is just a total hack - there's got to be a better way to
write that.

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.

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

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.

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

KPainter and the KPainter using QPaintDevices are my idea. VPainter was a
class which was implemented as part of Karbon. Both classes were created
independently, even if I based the public interface of KPainter on VPainter.

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

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

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

Not really. KGState is a helper class which out of convenience / lazyness
was put into its own header / source file.

The basic idea is to use KPainter calls whenever possible, which may mean
that the KPainter public API may be have to extended.

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

Regards
Dirk

If you want to keep