[Uml-devel] Re: karbon14 and uml

[Rob Buis]

Hello Andrew,

On Wednesday 02 April 2003 17:20, Andrew Sutton wrote:
> rob,
>
> i've been directed to you by dirk schönberger regarding vector drawing
> applications to be used by a uml editor. karbon14 seems to be exactly what
> we're looking for - it satisfies our minimum requirements (pretty and
> editable), but i had some questions.

Ok.

> it seems pretty natural that uml diagrams are a subset of vector drawings,
> but at the same time they're more and less complicated. for example, we're
> probably not going to have the need for all the graphics support within the
> application like gradients and alpha blends - we might use them, but we
> probably won't have the user configuraing them.

Yes, I understand. Cool effects, but not really crucial to the app.

> i'm kind of curious how integration might occur. it seems straightforward
> that we'd be required to link against the core library - if its a library.

Its not :}
I am CCing to Lenny, who did most of the core work (paths/visitors/document 
dom). IIRC there was talks of sharing these path routines and putting them in 
a lib. Only problem I see would be its closely tied to a painter abstraction, 
VPainter. So part of making this lib external involves making the painter 
abstraction public, or porting to something like KPainter.

> the graphical notations would be derived from VComposite (maybe). is there

Yes VComposite is the basis for lots of shapes, like rectangles/ellipses/stars 
etc. For instance you could derive from VRectangle and take as mem var some 
text string, and you'd have a box containing text. I think you'll find it not 
so hard to build new functional graphical objects from the existing family of 
graphical objects.

> anything else in the build environment that would be required or that we
> could take advantage of?

Well you soon end up with libart and/or Xr/Xc for the graphical stuff. OpenGL 
I dont know much about, so I'll leave it out.
Xr/Xc is currently not mature enough, or at least there is no easy way for 
users to add Xr/Xc to their system AFAIK. So we end up with libart, which may 
already be on users systems anyway.
Ofcourse we use freetype directly, but thats mostly a standard lib as well.
I guess there are some questions :

- is the canvas we use fast/versatile enough?

- can we agree on a useful/stable/flexible painter abstraction?

- can the karbon14 DOM and umbrello DOM (I assume its umbrello we are talking 
about here?) be easily "integrated" ?

I think most of such answers can be easily answered by building a (small) 
prototype.

Interesting info may be, that kivio, which you will probably have heard of, 
has shown interest in reusing karbon code. There is even partly working code 
for it, but the current decision is to postpone it until after next koffice 
beta.

More useful info, in that connectors are currently not represented in karbon. 
A possible porting of kivio should change this ofcourse.

So whats this U2? :)
Cheers,

Rob.