[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:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2003-02-21 22:30:21
[Download RAW message or body]

Good, I am going to try to explain why I would want what I have described (and 
what I have not described yet.)

I would like that KWord and KPresenter would get more common components, 
instead of having mostly two very different codes for similar tasks. Some 
(DTP-) power users having asked to add KPresenter features to KWord (for 
example picture backgroup or effects), so these similarities in code are not 
going to decrease.

I am not telling that this job is to be finished for KOffice 1.3. But I am 
seeing that we have not anymore a hard working Laurent Montel who worked on 
KPresenter everyday. In the past, when something like that happened to a 
filter (and to Kontour), it went dead. I would want to try to avoid this for 
KPresenter.

Having more common components means that we have a higher average of 
programmers per component, with a lesser risk of having to let die programs.

One possibility to achieve common code is that we tell the users to always use 
kparts. We would end up with lines, curves and similar handled by Karbon, 
pictures by Karbon too (cliparts) or Krita (images), text by KWord, tables by 
KSpread and so on. This approach would transform KPresenter into just a page 
tool on which you insert components. (There are many disadvantages. One is 
that the UI is probably not user-friendly. Two, it is that it is not 
filter-friendly either, as Karbon's export filters are document-to-file. 
Another disadvantage is probably memory use.)

Another possibility is that we use a UI-viewed approached. Users want to use 
lines in KPresenter and KWord, we allow to use them directly without having 
to run Karbon. Users want to insert a picture, we do it with KoPicture and 
not with Karbon or Krita. A user want to make a table in KWord, he can make 
it without using KSpread. (Major disavantage of this method: we have reduce 
common code between KWord/KPresenter but not versus Karbon. For filters, it 
is however better.)

Of course, the optimun would be to have an integrated UI and to use kparts 
behind the scenes. I have no idea how difficult it would be. (Nevertheless we 
would still have problems with the filters.)

That is how I see the future problems of KWord/KPresenter and some hints for 
solutions.

I am sure that some peope will disagree with me. ;-)

Have a nice day/evening/night!

On Friday 21 February 2003 20:11, shaheed wrote:
> 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

____________________________________
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]