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

List:       kde-core-devel
Subject:    Re: applyMainWindowSettings bug?
From:       David Faure <faure () kde ! org>
Date:       2008-05-04 11:26:25
Message-ID: 200805041326.27789.faure () kde ! org
[Download RAW message or body]

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@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).


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