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

[Parker Coates]

On Sun, May 10, 2009 at 9:36 AM, Alan Alpert wrote:
> On Thursday 07 May 2009 09:23:08 Alan Alpert wrote:
>> Okay, I think I've found the issue(s) (caveat: I've only had time to look
>> through the code and so have not yet tested my theory to confirm it. When I
>> have time, in a few days, I'll bring you test results if you don't already
>> have them).
>
> Wise caveat; now that I've tested my theory I've had to rework it. I still
> don't have a final solution but I thought I'd share my progress, and ask some
> questions along the way.
>
> On the plus side I have implemented a 'solution'. On my computer now I have a
> KAtomic that consistently only resizes itself once, both maximized and not
> maximized. But it's currently just a hack and there are multiple ways it could
> be properly solved.
>
> The details of how this is accomplished are as follows:
> It seems that the KMainWindow function that restores the window size provides
> a separate resize event to the initial resize (probably because it's outside
> the Qt kernel). This should be okay as long as it is consistently one resize
> event, if we need to save resize events then we skip the qt kernel one (so far
> it seems identifiable by WA_PendingResizeEvent being true inside the
> resizeEvent). The inconsistency from the KMainWindow function appears to be
> due to it ignoring things like panels and window decorations when trying to
> set the size inside the restore geometry function, and so it's too big and
> needs to get fixed later. It doesn't get fixed though if you remove the line
> that resizes it wrongly, which would explain why that line was commented
> 'WORKAROUND: this should not be needed." Modifying that line so that it sets
> the size correctly leads to it not being resized again if the window is
> maximized (if another resize event comes it's the same size and ignored
> earlier). The modifications however are exceptionally hack-y at the moment. The
> window decorations are compensated for with a '- 22' as I don't know how to
> get their dimensions(not that I looked very hard). The panels are compensated
> for by using availableGeometry instead of screenGeometry in the save and
> restore functions, but this may be a bad idea as the screenGeometry is saved
> alongside the window geometry so as to have different saved sizes depending on
> your desktop resolution. This issue though might be avoidable if the
> maximization state wasn't stored as screenGeometry+1 or if the unix code was
> unified with the windows code above it (I tried that quickly but there were
> problems, just like the comments suggested).
>
> It's looking like it's possible to 'fix' the workaround so as to always trigger
> the same number of resize events. What it's working around should probably be
> investigated, but I can't decide on what to do next. Whether to prepare a
> proper and working fix for the workaround, or just start investigating what
> it's working around in KWindowSystem, or try to unify the windows and unix
> code  for settings restoration (and give QWidget::showMaximized another
> chance) which might cause the problem to go away as well as clean things up.
> Which would be most useful (to start on at least)?
>
> In the end the expected code would be to ignore the first resize event only if
> we are successfully restoring geometry settings, and that can probably (still
> just a theory :) ) go inside of KMainWindow. This allows me to have happy
> dreams of KDE Games that only resize once without special code or timers to
> accomplish it.

I just checked and the extra resize event when launching a maximised
window does not show up when running our KDEGames under Windows XP.

Parker