must dispel misconceptions... :)

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

uml is a language for graphically communicating decisions/details of software 
architectures. as such, there should be a great deal of focus on the visual 
representation of information within diagrams - the best uml editors in the 
world (i.e. rose and visio) are insufficient for opposite reasons. rose sucks 
with graphics. visio supports uml via a plugin (which isn't bad, but its 
missing all the good analysis tools).

aside from that nobody does good automated layout. if the graphical components 
for umbrello have to be really, really ugly in order to look really, really 
good, then so be it. besides, V* has layers which might prove useful in the 
future.

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.

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

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

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

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.

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

those would extend to cover KShape objects?

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

this 3rd option can actually exist in tandem with the rest of the stuff. it 
all works very nicely - at least it is in my own mind :)

andy
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel