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

[Alan Alpert]

On Wednesday 06 May 2009 14:45:17 Ian Wadham wrote:
> 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.

I'm going to advance a different theory: that it works because it takes a bit 
of time and you got lucky. I've tried this approach myself and have once 
gotten multiple resizes despite going through ten 0ms timers before resizing 
the first time. This was with the game starting maximized and only once out of 
several tests though, and my timers weren't actually in the KXMLGuiWindow.

The variance leads me to believe that it isn't just that we need a couple of 
trips through the event queue, but that some external asynchronous event is 
resizing the window somehow. Maybe there is a dbus call asking for the size? 
It's very odd because needing one trip through the event queue makes sense, 
and it's not too hard to stretch this to multiple trips, but that should still 
be entirely deterministic in the number of event loops it takes.

My experience has been though that results vary more than one would expect, so 
I'd like to know if this approach works over a number of trials.

> 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 ... ;-)

If we know all of the cases and are committed to doing a workaround anyway, 
can't we just determine how many resizes we'll get and thus know how many to 
ignore? If you can easily determine whether you have an existing config file and 
whether the mainwindow state was maximized in it (the two variables I'm aware 
of) then you can know how many you'll need to ignore. This is a lot more of a 
hacky workaround though I think... and we need to know all cases where there 
is more than one resize and why.

> 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".
If it really is doing some sort of external asynchronous operation then this 
is the only good option. 

> 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.

--
Alan Alpert