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

[Wolfgang Rohdewald]

On Mittwoch, 6. Mai 2009, Ian Wadham wrote:
> 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].

I implemented his method in python. It works but I always got a small empty
window as soon as the QGraphicsView is built. Don't want that.


On Mittwoch, 6. Mai 2009, Alan Alpert wrote:
> 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.

Maybe. I thought I tried 0 ms and it did not work but maybe 
that was just such a case.
 
> 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? 

dbus-monitor while starting kmj. The only difference between starting
maximized or normal is this: (:1.8 is KWin) 

method call sender=:1.8 -> dest=org.kde.knotify serial=1950 path=/Notify; interface=org.kde.KNotify; member=event
   string "maximize"
   string "kwin"

and I cannot see anything else that looks relevant. But then I don't know
much about DBus.

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

last night it seemed to work permanently but now I also get mixed results.
Pending a real fix in kde/qt, that is good enough for me.

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

I checked the source code: Encoding this into the config file is done differently
depending on the platform. See 
http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/kmainwindow_8cpp-source.html#l00809
And you would have to parse the --geometry command line argument. So I personally
would not like to depend on this.

in kmainwindow.cpp I find possibly relevant resize() calls in 
::parseGeometry() and ::restoreWindowSize(). In both cases it depends on the
platform and the config file content whether resize() is called or not. But
it looks like resize() should never be called more than once from kmainwindow.cpp. And
qmainwindow.cpp has no resize() or setGeometry calls. I don't want to set up
a qt/kde development environment so I don't think I can do much more than reading
the source code.

-- 
Wolfgang