[Uml-devel] Re: karbon/umbrello

[Dirk Schönberger]

Andrew Sutton schreibt:

> 
> okay... i'm starting to get a better picture of our proposed general purpose 
> vector drawing lib. we have 3 parts to it:
> - the painter
> - the canvas/document
> - the path core
> 
> i'm not entirely sure what goes in the path core. certainly the core framework 
> for shapes (segments, lines, rectangles). would that also contain classes 
> such as gradients and fill rules? maybe? i took a look at the opal web page, 
> but didn't look at the source yet. i guess i should check and see what they 
> do.

At least currently I consider gradients, patterns and fill rules as render
related and handle them in kpainter.
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.
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. 

> > that would
> > probably imply not using things like KoRect and other koffice structures.
> 
> good idea.

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.

> > interchangeable), whereas VKoPainter was just something I hacked up
> > quickly.
> 
> i don't see why we just can't use KPainter to assume the responsibilities of 
> both VPainter and VKoPainter. 

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.

> it looks like dirk's KPainter::drawShape method 
> could be used as the hook for the path core (with KShape being the root > of the path hierarchy). cool.

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.

> > Right. I have no idea yet how common VDocument can be for the three apps...
> 
> i'm not actually thinking about a real document (like the document/view 
> architecture). in this case, the document is internally managed data that 
> allows the canvas to pass signals to the objects its managing, the canvas 
> should have weak ownership of its objects (like items in tree/list views). 
> it's still document/view, but for umbrello, at least, it only represents a 
> subset of the overall document.
> 

> > BTW load/save as it is now could have some implications. ATM for instance
> > karbon VComposite saves/loads svg path data.
> 

I agree with Andrew about the use of documents.
Things like SVG import/export could be handled as a visitor, i.e. on the
"path library" level.


Regards
Dirk