[Uml-devel] Re: karbon/umbrello

[Dirk Schönberger]

> its based, for the most part, on the maturity of the karbon framework. i
think
> there's some better object-orientation of drawing concepts in several
places
> - particularly the painter framework (like fills, strokes, gradients,
> patterns, etc.). i also think that KPainter has a slightly better
hierarchy
> for things like patterns (image pattern, solid pattern, etc). i can't find
> any rationale for why those wouldn't be split into subclasses of a base
> pattern class. it's a better separation of concerns. interfaces on
kpainter
> will be modified to reflect these changes.

KPattern is already supposed to have subclasses (KImagePatter,
KVectorPatter).
They currently just happen to be in on .cc / .h file.
Additionally, in order to implement KVectorPattern (i.e. a pattern which is
rendered using KPainter calls),
there is some missing infrastructure, namely a working meta-file
paintdevice, which I haven't found the time implementing, yet.

> as for the object model - KShape stays and so does VObject. i'm going to
> replace KVectorPath with VObject in the inheritance hierarchy. I think
that
> provides a really interesting way of looking at the object model. one
branch
> deals with really primitive shapes like rectangles and ellipses while the
> other implements a pretty complicated SVG-like object model. it should be
> sufficient for just about any application wanting to use the kpainter lib.

- are you really sure about using VObject directly? Please see my last mail
about this.
- 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.

> i'm still not sure on KCanvas. i suspect that i'm going to have
KCanvasElement
> be a wrapper of either a KShape. maybe. i still need to figure this out a
> little bit better.

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

> i'm also not entirely sure what changes would have to be made to other
> subdirectories within KPainter to support these changes... anyways, i'm
sure
> i'm skipping some stuff, but that's the basic gist of it. and no... i'm
not
> going to commit any changes. i'll just send a giant patch when i'm done in
a
> couple days :)

I'm looking forward to it ;)

Regards
Dirk