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

[Parker Coates]

On Wed, May 6, 2009 at 5:11 AM, Wolfgang Rohdewald wrote:
> 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.