2007/12/11, Ian Wadham <<a href="mailto:ianw2@optusnet.com.au">ianw2@optusnet.com.au</a>>:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, 11 Dec 2007 01:45 am, Aaron J. Seigo wrote:<br>> hm.. what's unfortunate is that Qt::WA_PendingResizeEvent is set to false<br>> *after* the resize event is sent (line ~5368 in qwidget.cpp) .. imho that's
<br>> incorrect, and makes it pretty much useless for testing whether or not to<br>> respond to the event. =/<br>><br>> ditto fro WA_PendingMoveEvent ...<br>><br>Are you sure, Aaron? It seems to me that it is the state of the *widget*
<br>that is being set and later tested, not the state of the resize event's<br>object. The event has been queued, in the situation you refer to, and<br>should not happen until after the qwidget.cpp code gives up control.
<br><br>BTW, I am deeply concerned about this issue, which could be a<br>showstopper for several KDE 4 games, including mine, but I'm on<br>the run at the moment and cannot elaborate. Please have a look at<br>my kde-devel post of Thursday 6 Dec, "SVG Rendering and Main
<br>Window Startup". You can get 1, 2 or 3 resize events, it seems,<br>depending on config settings at startup time.</blockquote><div><br>Just my 2 Cents:<br>I think this shows that doing a recalculation on a resize event is the wrong way.
<br>Maybe doing the recalculation on the first repaint event after a resize event would be a better idea. One has to make sure of course, that between the redundant resize events no repaint events are triggered.<br><br>Burkhard
<br></div></div>