From koffice Wed Apr 26 09:32:59 2000 From: Jost Schenck Date: Wed, 26 Apr 2000 09:32:59 +0000 To: koffice Subject: Fwd: Re: KOffice Library Cleanup? X-MARC-Message: https://marc.info/?l=koffice&m=95674228030122 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 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