[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-23 20:27:11
[Download RAW message or body]

> class KCanvasElement : public QObject {};
> class KShapeCanvasElement : public KCanvasElement
> {
>   KShape *shape;
> };
> class KOpalCanvasElement : public KCanvasElement
> {
>   OPAL::Morph *morph;
> };

> or something roughly like that. i don't think there needs to be any
tighter
> coupling between the two objects. KCanvasElement can define all the base
> signals and slots that each object should respond too or emit. users can
> further specialize these to provide additional stuff.

But how do you want to implement rendering?
In my idea the KCanvasDocument holds a list or tree of KCanvasElement, which
provide a render (KPainter&) virtual method...

> > VKoPainter (or at least the libart using stuff) never managed to
implement
> > a graphics state, which made operations like gsave() and grestore()
rather
> > difficult to implement.
> > KGState was implemented specifically to be able to implement this kind
of
> > stuff.
> > If you program your graphics Postscript style, the gstate will become
your
> > first tool, and you cannot live without
> > a porper implementation of it.

> right, but VKoPainter didn't use a paintdevice either. the state stuff
should
> be specific to the paint device. libartpaintdevice, i don't think,
requires
> the state management stuff - at least not like an eps type paintdevice.

Hmm, VKoPainter inherits from VPainter, and I tried deliberately to aoid
inheriting from KPainter as a backend.
For gstate: VKoPainter cannot easily implemet do something like

KPainter painter;

int numPoints = 6;
painter.moveTo (0, 100);
for (int i=0; i<numPoints; i++)
{
  painter.rotate (360 / numPoints);
  painter.lineTo (0, 100);
}
,

i.e. a affine transformation which has to be applied for each path segment
differently.
VKoPainter (and pure libart) applies the affine transformation to a
completed path/composite, which is less
flexible than I would like to see it.
Path building is not faster in libart than in LibartPaintDevice.

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]