[Uml-devel] Re: karbon/umbrello

[Andrew Sutton]

> At least currently I consider gradients, patterns and fill rules as render
> related and handle them in kpainter.

i just noticed that from webcvs. that seems like a very appropriate place for 
them since they're dependent on libart.

> The path library from Lenny handles things which see paths as
> geometrical/mathematical beings, instead of just rendering them.
> This means e.g. things like boolean operations, i.e. creating a result path
> from two original paths.

hmm... that might be an interesting extension of what's out there right now. 
would it be worthwhile to re-implement that functionality for a path library? 
or would it just be easier to follow the kshape/vobject stuff?

> There is currently some overlapped functionality, because Lenny again
> created some visual representation in Opal, namely EPS export and OpenGL
> display.
> Perhaps things like EPS export in Karbon could be used for
> exporting/importing functionality, e.g. for the different file formats
> Karbon supports.

> This depend upon if the target file format is more suited to an "object
> based" approach, like e.g. SVG, or more to a "render-like" approach, like
> Postscript.

i'm not sure how the ability to export fits in just yet, but umbrello will 
essentially have the same requirements. for umbrello, we're going to need an 
object-base format for storing information, but for exporting, it won't 
really matter too much. it would be nice if we could render diagrams into eps 
thumbnails (or can we do that with svg? it is "scalable" vector graphics :)

> I really like KoRect and KoPoint classes.
> Basically I see two possibilities:
>
> - putting them into kdelibs, renaming them to KRect and KPoint
> - a compatibility/support lib inside kpainter, which holds often used
> external classes. This library can be linked static.

i'd say this is the best bet. if we eventually move kpainter into kdelibs then 
KRect and KPoint become part of the standard API and, at least for now, the 
only place they're being used is for vector drawing stuff.

> VPainter and VKoPainter are rather legacy, at least if Karbon strts being
> ported to kpainter.
> Currently this is not feasible, because karbon is part of koffice, and
> koffice is in feature/code freeze.

that's fine. kpainter/kcanvas/path core won't be ready for real use for a 
little while.

> Yes, KShape is supposed to be used for this.
> You could also create some KShape subclass which contains more kcanvas
> specific functionality, like e.g. a method boundingBox(), which could be
> used to determine if a graphical element is "hit" by a mouse position. For
> this purpose I defined the kcanvaselelement is kpainter/kcanvas.

in your thinking, does the canvas element wrap a shape/vobject? to provide 
kcanvas coupling? i suppose it would be a good idea. that would enable us to 
implement kcanvas specific stuff in the element class while the shape/vobject 
contains user defined implementational stuff (like drawing and particular 
signal/slot interaction).

andy