applyMainWindowSettings bug?

[David Faure]

On Friday 02 May 2008, Vladimir Prus wrote:
> Lubos Lunak wrote:
> 
> > On Thursday 01 of May 2008, Vladimir Prus wrote:
> >> 6. Run application again. Expected result is the the window be maximized.
> >> Actual result is that the window is 200x200.
> > 
> >  http://bugs.kde.org/show_bug.cgi?id=150772 . Qt bug.
> > 
> >> I think what happens is.
> >> 1. KMainWindow::restoreWindowSize, when handling the maximized window,
> >> does not call resize(). Instead, it asks the window manager to resize
> >> the window.
> >> 2. QWidget::setMinimumSize does:
> >>      resize(qMax(minw,width()), qMax(minh,height()));
> >> since the size is not yet changed at this point, we explicitly set the
> >> size to whatever the size the widget already has.
> >>
> >> It seems that the only right solution would be to wait for the window
> >> manager to actually resize the window to whatever size corresponds to
> >> "maximized".
> > 
> >  No. If  memory serves me well, that's actually what happens and what is
> > causing the problem. The resizing in your step 2. actually happens _after_
> > the window is shown and maximized by the window manager, because of Qt's
> > delayed layout activation (or whatever it is exactly that triggers it so
> > late). 
> 
> In the real KDevelop case, it's indeed QLayout::activate that calls setMinimumSize.
> 
> > So the window is first maximized by the window manager and then the 
> > application immediatelly asks to be resized again (and width()/height() still
> > return old size because of X being asynchronous).
> 
> Is there no way to sync with X? Any possible workarounds?
> 
> Anyway, I've hacked this around by saving/restoring geometry(), and now I have
> two further questions about applyMainWindowSetting.
> 
> 1. Can I make it not restore size? Regardless of the bug, in KDevelop we sometimes
> use it to restore just toolbar position/settings. Currently, the function
> always restores window size -- can another version be introduced that does not
> do this?

Well, saveMainWindowSettings only saves the window size if d->autoSaveWindowSize was set,
which is probably how it works for other apps: if you don't want applyMainWindowSettings to restore the window size,
then don't save a window size during saveMainWindowSettings (then there will be no config key to restore).
But that's surprising behavior, though, when not using the "autosave" feature...

One solution would be to rename that bool to saveRestoreWindowSize and offer a way of
setting it directly -- but this assumes that an app always wants to save/restore it, or never.
And testing that bool in applyMainWindowSettings indeed, which would be safer than just
hoping there are no saved size-related keys if you don't want to restore the window size.
What do you think? (I can do that patch if you don't feel up to it)

The better (more flexible) solution would be an enum parameter in the applyMainWindowSettings method, but that's for KDE5 (virtual method).

> 2. I've noticed that if I try to switch toolbars into icon only mode, then
> with each save/restore cycles one toolbar moves to the left some amount. The problem
> seems that we first restore toolbar geometry, and then apply icon settings, that
> change toolbar size. The attached patch seems to fix that for me -- does it look
> OK to commit?

No objections. Maybe add a comment about why the order of things is important, in the code.

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