[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [Uml-devel] Re: karbon/umbrello
From:       Andrew Sutton <asutton () mcs ! kent ! edu>
Date:       2003-05-22 16:03:56
[Download RAW message or body]

> I didn't say that you should ignore it completely.
> IMHO we should use a layered approach.
> The lowest layer is something like KPainter / KPaintDevices, which takes
> care of the actual rendering using multiple possible backends.
> The second level is something like KShape/KCanvasElement/VObjects, static
> objects which can render themselves to a KPainter, and can intercept events
> like mouse and keyboard events. This I approached in my KCanvas, which is
> supposed to be more or less a port of Karbon's V* hierarchy.
> The third level is path manipulation, a.k.a. OPAL/C++. A KCanvas element
> could have a method like toPath(), fromPath(), where the results can be
> used for path manipulation calculations like in OPAL.

sure. a nice layered approach, but i don't think its quite right. i agree that 
the bottom layer needs to be the paint device... i also agree that the next 
layer needs to be the VObjects - or whatever we're going to see from opal++ 
:)

anything having to do with canvas's or widgets shouldn't be at this level. at 
the very least, what i take away from opal is that its useful to construct 
these objects without necessarily attaching them to anything. canvas elements 
don't quite describe this stuff.

the path manipulators are probably pretty tightly coupled to the path object - 
if i were to guess. i don't know. either these will be at the same level, or 
the manipulators will be at the next higher layer.

the canvas would be the highest layer because it provides the actual UI. i 
think that's the best way to look at this: from low to high layers:
- painting/paintdevice
- vector objects/manipulators
- canvas or whatever

> Another thing: I found a way to re-implement the whole set of SVG operators
> (like relativeMoveTo, relativeLineTo and the like). This again happens by
> heavy borrowing, this time from Xr code. What is the current state of the
> multiple current running sub-projects about KPainter? Is it ok if I change
> the public API of KPainter, and the list of supported primitives? Is there
> a timeframe when there will be again a stable set in KDE CVS? My time is
> currently rather limited, so it is okay if there is needed more time from
> your side....

i have to go back and re-evaluate some stuff before i can be really 
productive. plus, i'm waiting to see what opall++ looks like. feel free to 
make changes you see fit.

i'd really like to see integration between opals painting primitivies (color, 
gradient, pattern, stroke and fill) classes. those need to be standard across 
kde.

> For an idea about what I would like to achieve, imagine the public methods
> from kvectorpath as part of the public KPainter API.

cool. that's a good set of "primitive" drawing functions to build on.

as a suggestion... there's a bit of inefficiency in the libartpaintdevice 
implementation. you probably don't NEED to use the KGState to manage drawing. 
VKoPainter in Karbon just builds up the libart stuff as it goes. that might 
be more effective.

also, renaming KGState to KGraphState and KSegment to KGraphSegment (and 
putting them into an internal namespace) would help clear up some odd naming 
issues.

at some point, i'll come back and fix the kpaintdevice hack after any changes 
you need to make.

andy
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]