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

List:       koffice-devel
Subject:    Re: karbon/umbrello
From:       Dirk_Schönberger <dirk.schoenberger () sz-online ! de>
Date:       2003-05-07 22:03:42
[Download RAW message or body]

Hi,

> > Yes it was not intended as a shared lib from the beginning. OTOH its
> > reasonably abstracted
> > and just oriented towards vector graphics (hence the V :)).
> > That said, I suppose it could be made a shared lib. To make that work we
> > would have to  define useful, common base classes like VObject, VPath,
VText, VGroup etc.
> > The apps
> > can then build on this, for instance karbon builds on VPath/VComposite
the
shapes
> > VEllipse, VRectangle etc. etc. So I guess first step would be seperating
the common (base) classes and the
> > app specific classes built on top of them. Keep in mind kivio (visio
like
koffice app)
> > may want to use the base classes as well.
> > Maybe next step could be, determining minimum rendering properties
> > (fills/strokes/gradients/hatches etc.). And after that, maybe exact
demands
> > on the canvas, as I doubt VCanvas currently is optimized enough...

> I think the rendering model of VPainter (or perhaps KPainter) is a good
base
> for the above mentioned programs.
> I would like to refactor the V* class hierarchy as part of kpainter, i.e.
as
> shared lib. Basically I woule like to introduce the following base classes
> KanvasView (based on VCanvas, basically handles view functionality, calls
> the appropriate render element render methods)
> KanvasController (handles controller functionality, i.e. translates mouse
> and keyboard events to commands / actions), handles selections (currently
> selected KanvasElements). I think this class is currently not really
clearly
> implemented in Karbons V* class hierarchy.
> KanvasModel, based on VDocument, handles the model functionality. Holds a
> sequence of KanvasElements, delegates the controller actions to the
selected
> KanvasElements
> KanvasElement, the elements which are displayed, printed or otherwise
> rendered. I would like to base KanvasElements on my KPainterElement, i.e.
> they are rendered using KPainter. Additionally they can handle direct UI
> events (keyDown, keyUp, mouseUp, mouseDown, mouseMove, or translated calls
> from the model. I hope that VObject can be used for basic behaviour
> handling.

in order to keep this discussion going, I have updated kpainter again. I
introduced the new sub-project
kdenonbeta/kpainter/kcanvas and ported Karbons VCanvas to my new class
KCanvasView.
I also introduced the other classes, like KCanvasElement, KCanvasController,
KCanvasModel, but the classes currently have only the most basic interface.

Next steps IMHO would be to implement something like a
KCanvasDefaultController, which works together with the Model to manage
selections.
KCanvasElements should get most of the functionality of Karbon's VObject
The often needed classes, like rectangle, line, paths and the like,
hopefully can be implemented as KCanvasElement child classes.

You can browse the code e.g. via
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdenonbeta/kpainter/kcanvas

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]