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

List:       koffice-devel
Subject:    Re: [Uml-devel] Re: karbon/umbrello
From:       "Dirk Schönberger" <dirk.schoenberger () sz-online ! de>
Date:       2003-05-21 16:49:13
[Download RAW message or body]

Andrew Sutton schreibt:

> > > i finally figured out why KPainter and VKoPainter seemed so similar...
> > > hmm...
> > > same code ;) some of it anyway.
> >
> >  As Dirk already mentioned, still some fundemental design differences...
> 
> i guess i missed that. i'm not seeing the fundamental design differences any 
> more. the only real differences i'm seeing are in how things are actually 
> drawn - OO command objects (the VObject hierarchy) vs. method commands 
> (lineTo, moveTo, etc.). not really so different.

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.

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


Regards
Dirk

_______________________________________________
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]