[Uml-devel] Re: karbon/umbrello

[Dirk Schönberger]

Andrew Sutton schreibt:

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

The difference between VPath and VComposite is rather complicated.
Basically Lenny (as author of Karbon) and I (as KPainter author) both
wanted to introduce Postscript/SVG style vector paths, which are defined by
the following  features

- a path may consist of one or more subpath
- each subpath consists of several segemnts, each segments may be of
different types, the most often used segemnt types are line segments and
bezier curve segments. Other segment types are defined in the SVG rendering
model, but these types are mostly specializations of the basic types
(horizontal lineto as special kind of lineto, bezier curve with only one
control point instead of the normal two as specialization of the basic
bezier curve type a.s.o).
For historical reason Lenny decided to make the subpaths explicitly
accessible, so the two types "VComposite" and "VPath" were created.
VComposite implements the "multiple sub-paths" part, while "VPath"
implements the "multiple segments" part. IMHO this distinction is only
useful if you attempt to do vector manipulation, like boolean operations of
multiple vector paths. For the display work e.g. for Umbrello, this is not
really needed. Perhaps you need another mechanisms similar to grouping,
where each part of the group may be a complex vector path (including
subpaths) to. This allows you to decompose your widget/shape into the data
object relevant parts (like border, method list, property list, field list
in a UML class shape), instead of the render related parts (e.g. the
"border of a UML class diagram consist of a rectangle and two lines as
separators betwen the different lists)

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

Agreed. Besides, I think I made myself not clear enough. I would like to
use KCanvasElements (which are inherited from KPainterElements) to
implement the multiple application specific graphic element classes (like
UMLClassElement). These application specific element classes can be
composited of KShape classes, KShape is inherited from KRenderElement and
extends KRenderElement with methods for e.g. bounding box calculation,
affine transformation at a given point of the perimeter of the element
(thik things like "render text on or in a shape", hit tests (does the
coordinate (x,y) hit the shape (bounding box test, perhaps check for
filled/stroked) a.s.o.

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

It would be one possibility, but at least currently KPaintDevice is used as
a kind of hack, to be able to get the communication right. If there exists
more paintdevices and it becomes clear that gstate management is an often
used functionality, the paintdevices can be refactored to a common base
class.

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

Fine with me.

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

I think this should be possible with the KShape / KCanvasElement
distinction as mentioned above?

Regards
Dirk