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

[Alan Alpert]

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.

--
Alan Alpert