On Wednesday 19 Feb 2003 10:03 pm, Nicolas Goutte wrote:
> > I'd suggest a common lib for such objects, using a KoDrawingObject base
> > class or so, and then a KPObject and a KWFrameSet "wrappers" for
> > KoDrawingObjects. That way you can centralize code without having
> > to merge the object classes used by the applications (which wouldn't
> > make sense; the KWFrameSet/KWFrame concept doesn't apply to kpresenter).
> >
> > The wrappers would simply "forward" paint events, geometry changes,
> > and (mouse) events to the KoDrawingObjects.
>
> That seems to be very much like one of the ways that I wanted to check.
> However your idea goes further with the use of KoDrawingObject..

I think this would be an interesting idea IFF Karbon drawings were adapted to 
be the superclass of KoDrawingObject. And that is clearly a problematic 
approach. Why? Apart from the obvious, because you just reinvented the MS 
Office approach of thinking that a common datastructure corresponds to a 
common UI. Just think:

- two slightly different ways to draw a line in KOffice apps.

- two sets of (e.g. printer or export) filters for the slightly divergent file 
formats.

and then change "two" to "n" when this sort of drawing feature gets added into 
kspread, kpresenter,... too. See my other note for what I think is a better 
approach.

Thanks, Shaheed
____________________________________
koffice mailing list
koffice@mail.kde.org
To unsubscribe please visit:
http://mail.kde.org/mailman/listinfo/koffice