kmainwindow settings group (Re: KDE/kdelibs/kparts)

[David Faure]

On Thursday 22 February 2007, Stephan Kulow wrote:
> Am Mittwoch, 21. Februar 2007 22:34 schrieb David Faure:
> > On Wednesday 21 February 2007, Stephan Kulow wrote:
> > > SVN commit 636048 by coolo:
> > >
> > > whatever happened
> > >
> > >
> > >  M  +2 -2      mainwindow.cpp
> > >
> > >
> > > --- trunk/KDE/kdelibs/kparts/mainwindow.cpp #636047:636048
> > > @@ -176,8 +176,8 @@
> > >  void KParts::MainWindow::saveNewToolbarConfig()
> > >  {
> > >      createGUI( d->m_activePart );
> > > -    KConfigGroup *
> > > -    applyMainWindowSettings = new KConfigGroup(KGlobal::config(),
> > > QByteArray()); +    KConfigGroup cg(KGlobal::config(), QByteArray());
> > > +    applyMainWindowSettings(cg);
> >
> > Hmm, again an empty group... which wasn't empty in kde3.
> > The code applyMainWindowSettings said:
> >     KConfigGroupSaver saver( config, configGroup.isEmpty() ?
> > config->group() : configGroup ); and configGroup was a parameter with an
> > empty default value.
> > So it was saving into "the current group". This was quite broken, on
> > retrospect. The goal is to always store the settings for a given type of
> > mainwindow (e.g. kmail composer window) into the same group (e.g.
> > "composer"). Whether we're doing that explicitely, via autosave, or after
> > "OK" in the toolbar config dialog like above.
> > So I think we should store the group into a member var, a bit like
> > d->autoSaveGroup - but even if not enabling autosave (=> I would rename it
> > to settingsGroup - like the method that we found was redundant ;)
> >
> > But that means changing apply/saveMainWindowSettings to take a KConfig*
> > again :(
> 
> I'm not sure we should go there, but let's analyze KDE3 use cases:
applyMainWindowSettings is the easy case, you're missing my point.

The quoted code above applies the last-saved mainwindow settings after
editing toolbars. This is the only way we can hide again the toolbars that
were hidden by the user, etc.
However, how can it know the group to use?

Case 1: setAutoSave was called, so that kmainwindow saves settings automatically
after moving/enabling/disabling toolbars etc. (a recommended practice, especially
for apps with potentially multiple mainwindows). In that case saveNewToolbarConfig()
can just use the autosave group to load the settings again - no problem.

Case 2: autosaving not enabled, the application manually calls applyMainWindowSettings
and saveMainWindowSettings - now with a kconfiggroup in kde4.
 => how can the above slot possibly know from which group to read the settings?

Since we need that group for apply/save or setAutoSave, and internally for saveNewToolbarConfig
(there's one in KMainWindow too, the kparts one is just a specialization), I'm suggesting
to just set it once and for all.

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