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

List:       koffice-devel
Subject:    Re: koMainWindow issue
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2001-05-07 22:36:04
[Download RAW message or body]

On Mon, May 07, 2001 at 10:32:41PM +0100, David Faure wrote:
> On Monday 07 May 2001 05:29, Werner Trobin wrote:
> > David Faure wrote:
> > > 
> > > Hi there :)
> > > 
> > > We (Simon) converted all koffice apps to NOT inherit from KoMainWindow.
> > > That looked good, but now the following questions arise:
> > > * what are the virtual methods in KoMainWindow good for, then ? :)
> > > * I want to do something when the document-info dialog gets closed
> > > (namely, update the relevant variables in KWord). Should I re-add a
> > > KWMainWindow (or KWShell, whatever :), to reimplement slotDocumentInfo,
> > > or should I add a signal to KoMainWindow that says "documentinfo changed" ?
> > 
> > IMVHO Simon changed that some time ago because all applications
> > did nearly the same. If you need a different behavior than the
> > default one (which should be used by plain vanilla KOffice apps)
> > then I suggest inheriting. KOShell does the same, btw.
> 
> Hmm, good point (forgot about KoShell).
> 
> > > I'm asking because I'm not too sure which way we want to go.
> > > Not inheriting a class and providing virtual methods in that class
> > > are a bit contradictory :)
> > 
> > Right now we need at least some of them for KOShell. I think
> > it's okay to share the common code in KoMainWindow, but we shouldn't
> > try to put everything there (then the API will look like the KoDocument
> > one in a few months :p )
> 
> Hmm, I'd agree, but just how to I do that ?
> 
> It seems that KoDocument used to have a 
> KoMainWindow * createShell()
> [which krayon reimplements btw].
> But this doesn't exist anymore, and the code in kofficecore
> (koApp, koDocument and koView) do a direct new KoMainWindow() where
> they could do doc->createShell() instead - if it still existed.
> 
> Readding it would be BIC :(
> 
> So I'm back to square one: AFAICS we forbid inheriting koMainWindow
> from a normal koffice app (excluding koshell here :).
> Shall I add a signal documentInfoChanged() then ?
> Could even be a signal of KoDocumentInfo itself, if we want to
> keep KoDocument clean (my suggestion of adding the signal to
> KoMainWindow was even more wrong I realize).

Hmm, this sucks, indeed (forbidding inherittance from KoMainWindow) ,
and I agree that a virtual createShell() sounds like the right approach :-}
(damn, I forgot that when I removed the shells :-(

Hmmmm... maybe we could use the factory for that?

Like you call the factory with 'KoMainWindow' as classname, and the
implementation of the factory in the library looks for that?
If a factory does not implement it then it returns 0, which we can
catch in KoDocument::createShell() and do a new KoMainWindow. And we
add a // ### KDE 3.0: make virtual as comment ;-)

But I have that strange feeling that I forgot something :-)

Bye,
 Simon
_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel

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