createStandardKWindow()

David Faure faure at kde.org
Tue Jun 8 15:51:05 BST 2004


On Tuesday 08 June 2004 16:35, Simon Hausmann wrote:
> On Monday 07 June 2004 19:35, David Faure wrote:
> > > > > > 3) createStandardKWindow() Name it something else?
> > > > > > createKMainWindow() createStandardKMainWindow() 
> > > > > > createStandardWindow()  ?
> > > > >
> > > > > It's in the KMainWindow namespace already, so no need for KMainWindow
> > > > > in the name. But in fact this isn't "creating"... That's what the
> > > > > constructor did. This is more about activating a number of automatic
> > > > > features.... setWindowFeatures? enableMainWindowFeatures?
> > > >
> > > > Well if you have something that is "enable" you might think you can
> > > > disable it.  I removing the K and changed it to createStandardWindow() 
> > > > sense it can create actions and it could create the GUI  if Create is
> > > > passed.
> > >
> > > <strong>but it does not create a _window_!!!</strong>
> > > i suggest setupFeatures() or addFeatures() or something like that.
> >
> > setup() or setupGUI() (close to createGUI since it replaces it) sound good
> > to me.
> 
> IMHO the new method should be an overload of createGUI, combined with the 
> removal of the 'Create' option.

Then those features would not be available to KParts::MainWindows, since they
have to call another createGUI method (the one with a Part*).

Hmm, or you would add the flags to both createGUI variants, and factorize the code
in a KMainWindow::setupGUI method (which would then be @internal)?

But IIRC we call createGUI(Part*) every time a part changed, so this wouldn't work.
We really want to setupGUI once (to create some actions etc.) and createGUI many
times (in the KParts case).

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).




More information about the kde-core-devel mailing list