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

[Casper van Donderen]

I used to do this using QApplication:desktop().width() (on a Qt app) I do not know if there is a kde equivalent for this...

Casper 
-----Original Message-----
From: Parker Coates <parker.coates at gmail.com>

Date: Wed, 6 May 2009 08:22:49 
To: KDE games development<kde-games-devel at kde.org>
Subject: Re: [Kde-games-devel] does this solve the multiple resizing bug for
	you?


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.

From the research I did on this topic a couple months ago, I
discovered that the maximising resize event is handled by a call to
KWindowSystem. On X11, KWindowSystem seems to handle the maximising
through that DBus call you found. As a result the call is asynchronous
and outside the application event loop, so we have to play games with
timers. Timers are nasty because they'll cause unnecessary delay on
fast systems, and insufficient delay on slow systems (which need the
delay most).

If there were a way to synchronously determine the size of a maximised
window, maybe we could manually set the window to that size ourselves
before showing it. Later on KWindowSystem could do it's thing and
"officially" maximise the window a bit later, but the main window
itself wouldn't get a second resize event.

I think we need someone with some window system expertise.

Parker
_______________________________________________
kde-games-devel mailing list
kde-games-devel at kde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel