[Uml-devel] Re: karbon/umbrello

[Dirk Schönberger]

Andrew Sutton schreibt:

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

I think at least currently it is not necessary to use the path lib for
things like umbrello. Path functionality is more useful in a general
purpose graphical editor like, e.g. Karbon.
If necessary, the application specific kcanvas classes, like for Umbrello,
could get a method like 

  KPath path();

to be used with the path library.

> 
> > 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 think you should discriminate between storing the "Umbrello object
model" and storing the "graphical representation". For the object model I
would think something like XMI should be used, while the graphical
representation could be rendered using SVG or EPS. EPS is currently slighly
better supported in KDE, even if you have to call an external application,
namely ghostscript. The SVG support currently is in its infancy, basically
there are multiple projects which mostly accessing libart directly.
Part of kpainter is my approach for rendering SVG, but it is also in its
infancy.
I suppose you could use SVG exporting code from Karbon to implement a SVG
paint device. I have, however, not explored this further.
There exist also EPS (or rather AI, while AI can be build from a call to
ghostscript) importing code for Karbon.

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

KoRect and KoPoint are used heavily in KOffice, I think (at least that's
where the classes come from). So we have already multiple users, which
could allow for direct inclusion into kdelibs. However, I would be not
quite sure about where to include them.


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

Currently I see two possibilities:

- you could inherit directly from KCanvasElement and implement the
graphical representation and hit tests for yourself
- you could use composition (a diagram element consists of a kcanvas
rectangle, a kcanvas text element and some kcanvas line elements)

The way you choose defines the changes which have to be done to kcanvas.
If you use an internal implementation of hit test and rendering, it would
be superfluous to port things like VRectangle, VPath, VText, VLine to
kcanvas.

Regards
Dirk