[Kde-games-devel] does this solve the multiple resizing bug for you?

[Ian Wadham]

On Wed, 6 May 2009 1:26:58 pm Wolfgang Rohdewald wrote:
> I found something that works for me:
>
> 1. in the KXMLGuiWindow constructor fire a singleShot Timer. 1 msec is
> sufficient. 2. define a corresponding event that fires another singleShot 
> Timer. 1 msec is sufficient. 3. define a corresponding event that finally
> allows the resizing method to do something.
>
> this only takes 2 msec, and it does not have the drawback that an empty
> window appears when the first QGraphicsView constructor is executed.
>
It might also work if the single-shot timer is zero msec.  That is a time
honoured technique for handing control to Qt's event queue briefly.

> the first timer prevents one resize for starting with normal window sizes
> the second timer prevents the extra resize for starting with a maximized
> window size.
>
> This works here with qt4.5.0 and kde4.2.2. So I have some uncertainties:
>
> - does it work with other versions?
>
> - does it also work in a C++ program?
>
> - why does it work at all? I have no idea. I just saw that Alan Alpert
> posted a patch for KAtomic using timers, so I experimented with timers.
>
It works because each stage hands control to Qt's event queue, which
allows resize events and other events to happen, with a timer event
coming last in the series each time around.

KGoldrunner, since about 15 months ago, has been using a "constructor
extension" in the main window object (kgoldrunner.cpp) [1], which is called
by using a queued procedure-call (rather than a timer) [2].  A second queued
call goes to KGrGame::initGame, where the graphics starts getting done.
Again it works because it lets Qt and KDE take some trips through the
event queue before starting to render and paint.

BTW, you can *load* the SVG at any stage ... just so long as you do not
render and paint it until you know the final size in pixels.

> - are there still special cases with more than one resize?
>
Not that I know of ... ;-)

What mystifies me is why we have to do these workarounds.  It has been
suggested several times, by others as well as me, that KMaindow and
friends should only issue *one* resize event.

Failing that, maybe a simple "signal" to say "KDE libs has finished setting
up the main window".

All the best, Ian W.

[1]  http://lists.kde.org/?l=kde-games-devel&m=120071267328984&w=2
      2008-01-19 "SVG and MainWindow resize handling", Ian Wadham
[2]  See QMetaObject::invokeMethod() re queued procedure calls.

P.S. KGoldrunner logs the above sequence of events on its stderr output,
which might make it easier to follow.