[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [Uml-devel] Re: karbon/umbrello
From:       Andrew Sutton <asutton () mcs ! kent ! edu>
Date:       2003-05-21 16:51:38
[Download RAW message or body]

> VObjects are not really intended as command objects, but more as a Document
> Object Model, i.e. a tree of graphical objects which may be persisted at
> times. The tree can be modified at runtime, e.g. by the visitor classes.
> The methods and primitives in KPainter and the paint devices are supposed
> to be "fire and forget", i.e. you don't really want to change them after
> they are created. A special case of a paint device, the metafile, can be
> used to store drawing commands, so that they later can be played again and
> again. But it is still of no use to change the stored commands.
> On the other hand it would be useful to manipulate the VObject /
> KCanvasElement tree. If you have proper event handling, you could implement
> optimized re-rendering of the view, which is not possible with the KPainter
> approach.

okay.

> I think both designs complement each other. Unfortunately this leads to a
> limited effect of redundant implementations, which hopefully can somehow be
> solved.

there are certainly applications where "fire and forget" would certainly be a 
more appropriate drawing technique than the construction of an object tree. 
conversely, an object tree might be better suited for other applications. in 
this case, i think the redundancy is a desirable facet to the implementation. 
its certainly more desirable than forcing developers into one drawing 
technique. besides, who's to say how any of this stuff gets used in the 
future :)

looking back at the original kpainter code, it looks like i may have 
over-estimated the amount of work. aside from a sizeable code cleanup and 
documentation effort, i'd say that its almost there. all that we'd really 
need to do to integrate the two things is to tweak the VObject stuff to use 
the K* painting classes (not overly hard) and lose the other V* dependencies.

i'd like to see what the c++ opal core looks like before moving forward on 
anything. there might be some things that have been missed in both KPainter 
and Karbon that have been caught this time around. no pressure, rob ;)

andy
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]