[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-25 8:34:00
[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?

> YourVeryOwnRenderingVisitor v.visit( *morph );

Mabe I misunderstand something, but if you decouple KCanvasElement from the
actual renderer, you have to
make the document classes (KCanvasDocument / VDocument) a more complex class
hierarchy than I thought.
My idea was to make KCanvasDocument itself a rather "intelligent" class, at
least it could handle rendering by calling the appropriate rendering methods
from its canvas elements. Because the document knows enough about its
elements, it could handle things like optimized rendering (drawing only the
parts which are afected from the latest changes.
I your proposal you seem to have to implement this functionality in children
of KCanasDocument, i.e. in KarbonDocument, UmbrelloDocument, KiioDocument,
separately?

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]