[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice
Subject: Re: Experiences with KWord 1.2.1 (KDE3.1)
From: shaheed <srhaque () iee ! org>
Date: 2003-02-21 19:11:13
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic