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)
    - 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 ;-)

   OTOH KoDocument has keeps a reference to KoMainWindow, so it's a
   circular reference. (making a direct move to kofficeui impossible)

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.
>