[Uml-devel] Re: karbon/umbrello

[Dirk Schönberger]

> must dispel misconceptions... :)

I think so I will have to too...

> so... while the KShape framework is appropriate for what i want to do, the
> VObject framework gives me alot more control over how diagrammatic
elements
> are going to be rendered - which i like very, very much. besides, the only
> real difference in the two object models (besides the obvious) are the
name
> of the "draw" method. KPainter uses "render()", VObject uses "draw()".
adding
> support for VObjects should be almost trivial by adding a
drawVectorObject()
> method to KPainter - thereby supporting KShape and VObject object models.

My idea was to refactor the V* framework out of Karbon into my external lib
(in KPainter), so
that it could be used independently of any koffice libs. Hopefully Karbon
could use the same libs, i.e.
the V* class library becomes the KCanvas* library. The classes should have
the nearly the same public interface and the same internal implementation.
Minor details, like if the render method should be called "paint()", or
"render()" are negotiable ;)

Using Karbon V* classes directly would mean that you will have to render the
whole libraries, inclusive libkarbonpart and likkofficecore/libkofficui. I
don't think this is desired.

> we are using XMI for the data model. actually, i think umbrello2 might
have
> the most robust xmi parser in the world right now - even though it doesn't
> currently parse UML :) anyway, XMI/UML don't really define how we store
> graphics information at all so i'm going to end up having to create some
kind
> document model for diagrams. i like the VObject stuff because we can save
and
> load SVG directly from the vector objects. although i will have to augment
> that with our own specific attributes and elements for describing various
> display properties.

I have no real problems with porting * to KCanvas* directly, but I am not
quite sure if this is really useful.
IMHO things like saving/storing to SVG should be part of another library,
like a C++ified OPAL.

For own specific attributes, do you have any specific ideas? I have seen
custom SVG extended grammars and I don't really like the idea.

> i suppose i could use an EPS object model, but inside information tells us
> that UML 2.0 is going to include SVG as part of the standard for
transferring
> diagrams within models. either way, there's going to be a specialization
of
> something going on :)

EPS has no real object model, but only some kind of render informations.
You could use some kind of extended Adobe Illustrator file format, where
there is at least a defined way to add extensions.

But why do you want to store mixed content (UML object model and graphical
representation) anyway?
Doesn't it succeed to e.g. use a container format like KZip and store the
XMI, SVG and other meta data with it?
OTOH whis would mean that you would have to use more koffice features than
expected...

> i was thinking about that too. we could make a little static lib in the
> support dir to define KPoint, KRect (which are renamed from KoPoint,
KoRect).
> that wouldn't be too bad - just link KPainter, etc. against it. as
mentioned,
> kofficeui is a pretty heavy link for just 2 smallish classes.

Fine with me. Or they could become art of e.g. libkdeui.

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

> those would extend to cover KShape objects?

My current idea is that KCanvasElement takes VObject source code and
inherits from KShape.
KCanvasRectangle inherits from KCanvasElement and uses the code from
VRectangle.
KCanvasPath inherits from KCanvasElement and uses the code from VPath.
KCanvasText inherits from KCanvasElement and uses the code from VText.
KCanvasLine inherits from KCanvasElement and uses the code from VLine.

Things like VSelection become internal details of things like
KCanvasController.

> i see a third for the VObject stuff...
> - a KCanvasVectorElement (or something similar) holds a pointer to a
VObject.
> since VObject already supports a bounding box, it wouldn't be overly hard
to
> implement object selection for contained VObjects. events/actions
generated
> by selection, keypress, etc. can be passed to the underlying VObject or
> intercepted by the containing canvas element to implement generic actions
> (cut, copy, delete, etc).

Again, using VObjects directly would mean to libkarbon / libkarbonpart and
the koffice libs.

Regards
Dirk