Extra resize events from KXmlGuiWindow

Parker Coates parker.coates at gmail.com
Mon Mar 30 15:36:38 BST 2009

On Sat, Mar 28, 2009 at 6:15 PM, Ian Wadham wrote:
> Qt's "Scribble" example might be a simple enough Qt-based instance of
> the extra resize problem: source at $QTDIR/examples/widgets/scribble ...
> I inserted some code in file scribblearea.cpp, ScribbleArea::resizeEvent,
>    static int num = 0;
>    num++;
>    qDebug() << "Resize Event:" << num << "W" << width() << "H" << height();
> and got this output, at startup time (the app code does a resize to 500x500):
>    Resize Event: 1 W 500 H 498
>    Resize Event: 2 W 500 H 474
> So this does seem to be a Qt 4 "feature" ...  What now?

This morning on IRC, David pointed me to his workaround code in the
Konqueror unit tests [1]. I applied it to KPat and it does, indeed
skip the resize event related to the delayed menubar insertion.

It does not, however, eliminate the extra resize event when the window
was maximised on last run. That resize seems to originate from
KMainWindow::applyMainWindowSettings() which calls
KMainWindow::restoreWindowSize() which seems to be platform dependent.
Since all this is happening in the KMainWindow constructor which is
called before setCentralWidget, I wouldn't have expected it to cause
any trouble, but maybe the KWindowSystem calls used on X11 are

So we've made progress, but we're still left with some questions:
- Should we report QMainWindow's delayed menubar insertion as a bug in
Qt? Sure David's workaround works, but it doesn't seem like it should
be necessary.
- Should David's workaround be moved somewhere so we can use it
consistently? I guess this depends on the above.
- Does the maximised resize event show up on other platforms? Is it
realistic to think that KMainWindow could be modified to avoid it



[1] http://lxr.kde.org/source/KDE/kdebase/apps/konqueror/src/tests/konqviewmgrtest.cpp#057
kde-games-devel mailing list
kde-games-devel at kde.org

More information about the kde-core-devel mailing list