[Uml-devel] Re: karbon/umbrello

[Andrew Sutton]

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.

> Keep in mind though that not every class that starts with a V will be
> appropriate outside karbon.

good point. i suppose classses like VSelection will probably have application 
specific counterparts for the canvas/document component to this lib.

> I dont see the MI problem? Probably I am overlooking something, you may
> reuse the classes in another way I imagined or so...

just from a brief glance it looks like the putting a QObject base on top may 
be capable of introducing a "circle of death" situation - but i may be 
reading too much into it.

> Well IIRC Lenny wanted to make a core path lib not limited to karbon. So
> that would
> probably imply not using things like KoRect and other koffice structures.

good idea.

> They are close, but with a slightly different philosophy. KPainter tries to
> stick
> to QPainter/QPaintDevice abstraction (so KPainter and QPainter should be
> 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. 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.

> Phew :)

hehehe. 

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

we really have 2 components to saving graphical information. for the most part 
we don't actually care about saving the static image - just information that 
can be used to recreate the thing. in otherwords, we're just saving 
parameters so we'll have to invent our own document model for that stuff. we 
can, however, save svg within that context to create static documents (that 
can be scaled for thumbnails or easily exported).

> KPainter should be restricted to painting :) I am not very good at coming
> up with
> names, but vector should probably be in it :)

i'm not good with names either, but i think dirk has the room and a good 
start, if not the best name for what we're thinking ;)

> I really hope you have lots of time. Ofcourse I am interested a lot in this
> stuff and
> willing to help as much as time permits.
> Cheers,

i have nothing to do for the next... 3 weeks maybe before summer sessions? at 
least i don't think so. i don't even know if my advisor is going to be around 
to give me research to do or if my "research" is going to be working on 
umbrello :) one can dream.

assuming i ever get anoncvs to work, i'm going to start hacking the path core 
(the shapes and such) over to the kpainter/path directory. that sounds like a 
good place for them. i'm also going to start building signal/slot support for 
the path core and seeing how/if i can integrate that into the canvas stuff. i 
don't really want to touch the graphics part... that sounds too hard :)

andrew sutton
ansutton at kent.edu