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