[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Fwd: Re: KOffice Library Cleanup?
From:       Jost Schenck <uzsnty () uni-bonn ! de>
Date:       2000-04-26 9:32:59
[Download RAW message or body]

I got this message with: X-Diagnostic: Not on the accept list
David, are you subscribed with david@mandrakesoft.com?
-Jost.

----------  Forwarded Message  ----------
Subject: Re: KOffice Library Cleanup?
Date: Wed, 26 Apr 2000 10:49:27 +0200
From: David Faure <david@mandrakesoft.com>


On Wed, Apr 26, 2000 at 09:24:21AM +0200, Simon Hausmann wrote:
> 
> 
> Slightly related I have to things in my mind regarding
> libkofficecore/libkofficeui:
> 
> 1) KoMainWindow is currently in kofficecore. However I get the impression
>    that in somehow it belongs to kofficeui (IMHO)
>    Two reasons:
>     - it is a GUI class (it inherits KTMainWindow/QWidget (ktmainwindow ->
>       kdeui)

The core/ui distinction in KOffice has always been a bit special ;-)

>     - I once thought of implementing a dialog for the koffice document
>       property/info stuff (author, email, summary, company, etc.) .
>       IMHO the code for launching it belongs to the shell -> KoMainWindow
>       However that is impossible, as the dialog for configuring it would
>       belong to kofficeui (-> cannot launch dialog from kofficecore ;-)

Unless the dialog is in kofficecore ;-)
Currently the distinction is more:
kofficecore = the core classes for any KOffice application, including UI
kofficeui = a set of shared UI tools and dlgs, not strictly necessary but useful

We can change that, but if you don't want to, you can as well put it
in kofficecore.

>    OTOH KoDocument has keeps a reference to KoMainWindow, so it's a
>    circular reference. (making a direct move to kofficeui impossible)
Ah yes, createShell(). Necessary in this very document-centric design.
I think we can't change that and we have to keep KOMW in kofficecore.
This is what makes possible to have all the code centralised in KoApplication:
it can create documents and shells for any KO app, by getting hold
of the document-entry, then the document, then creating a shell for that
document (e.g. a KWordDocument creates a KWordShell).
Going back to any solution where the document can't create its shell
means going back to much duplicated code in main() or K*App.

David.

> 2) There is still one really nasty activation bug:
>    Imaging a KSpread document and embedded in it another child document.
>    Now activate the child document. This creates a frame around the
>    embedded view. Now clicking on the frame area (which used to be drawn
>    correctly but for some strange reason isn't anymore (you just see the
>    changed mouse cursor) should not activate the parent document but
>    keep the child document active while making it possible to move the
>    child view by dragging the frame. This used to work, but for some
>    reason it is broken. I tracked it down to the point that the frame
>    QRegion in the KoDocumentChild does not seem to be calculated
>    correctly. Therefore the frameRegion().contains( point ) call fails,
>    KoDocumentChild::hitTest returns 0L (iirc) and the part document
>    gets activated.
> 
> 
> Any ideas? :)
> 
> Ciao,
>  Simon
> 
> On Mon, 24 Apr 2000, Werner Trobin wrote:
> 
> > Hi!
> > 
> > I'm still trying to understand every single detail of
> > kofficecore and I have to admit that I have little
> > problems with some parts of it.
> > 
> > I don't know if I'm right, but some classes of the libs
> > seem to be rather obsolete or at least useless with the
> > new kparts stuff. I know that "it works," but there are
> > some strange bugs and the error handling is broken in
> > some classes. We've already had some discussion and even
> > a rewrite of some parts because of QDom, but I think we
> > should use KOML for the parts still using it till 1.0.
> > Maybe we should change this after KOffice 1.0... but I'm
> > not the person to decide that :) (but at least I'd
> > volunteer to help porting :)
> > 
> > Therefore I'd like to ask if you (mainly Reggie, Torben,
> > (David?),...) would be so kind to have a look at every
> > single class/method. As KDE2 and the first official
> > release of KOffice are just around the corner we should
> > try to make the libs as stable and slim as possible.
> > 
> > I don't know the release schedule, but I can imagine that
> > a KOffice 1.1 will be released soon after 1.0. Maybe even
> > other people start to write KOffice parts and we shouldn't
> > change the libs radically after 1.0 IMHO :)
> > There is also this "binary compat." thingy like in the
> > kdelibs. Currently only a few kofficecore classes use a
> > private data ptr and so on.
> > 
> > Well... now the funny part: I volunteer to help cleaning
> > up the libs, porting the apps, and so on, but some expert
> > has to tell me what to do :)))
> > (The only classes I could clean up are the filter related
> > ones like KoFilter, KoFilterDialog, and KoFilterManager)
> > 
> > What do you think of this? Is this possible for our Qt
> > wizards after 2.1 finally has been released now?
> > 
> > Werner
> > 
> > P.S. CCed this mail to Torben because I think he is not
> > subscribed.
> > 

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

[prev in list] [next in list] [prev in thread] [next in thread]