Review Request 114484: Fix KMainWindow size management, esp. on asymmetric multiscreens

[Thomas Lübking]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/114484/
-----------------------------------------------------------

Review request for kdelibs, Christoph Feck and Martin Gräßlin.


Bugs: 286146, 317760 and 324957
    http://bugs.kde.org/show_bug.cgi?id=286146
    http://bugs.kde.org/show_bug.cgi?id=317760
    http://bugs.kde.org/show_bug.cgi?id=324957


Repository: kdelibs


Description
-------

Due to the many patches arriving to kdelibs, i just thought to give it a try ;-)

Notice that i did not align the non unix/x11 preproc branches, but will in case it's accepted.


tl; dr
======

situation now:
--------------
- on multiscreen setups with different sizes
  * KMainWindow may open with the "wrong" size (286146)
  * KMainWindow may open on the "wrong" (not active) screen
- maximized KMainWindow re-opens maximized, but lost its unmaximized state
- windows that randomly cover the maximum width of height will falsely open maximized in that direction (317760)

situation after:
----------------
- on multiscreen setups with different sizes
  * KMainWindow will open with the last size
  * KMainWindow will (usually, see details) open on the active screen
- maximized KMainWindow re-opens maximized, unmaximizing will restore the previous maximized size
- we should be able to remove the kludge that causes bug #317760 from KWin (KMainWindow is explicitly referenced there and the behavior is unspecified and undocumented)


--------------------------------------

En Detail
=========

I started out by seeking a fix for bug #286146
The issue here is that KMainWindow handles the size in relation to the current screen resolution.
The "current screen resolution" is the one of the screen where the window is.
This happens *before* the WM places the window (eventually selecting another screen)
If the screen changes or if you just closed it on the other screen before, you'll not get the size you'd expect (because it had a different size when you closed it and/or even does not match the size stored for the screen it opened on)

In addition to that, the size may be "too big" for the active screen (in which case kwin will place it on the fitting screen rather than dropping borders)

There're 5 possible solutions to this:
1. KWin does not alter the screen (ie. move the window to the "active" screen) for the window
2. KMainWindow knows the target screen
3. KMainWindow anticipates the target screen
4. KMainWindow restores its size *after* being mapped and placed by the WM
5. KMainWindow treats the combined screens of the multiscreen as one for the size management

ad 1)
No. :) Plus, there'd be no guarantee for the behavior on other WMs

ad 2)
Unfortunately NETWM is completely multiscreen unaware, so there's no protocol in place, so it could be a KMainWindow & KWin related "solution" only

ad 3)
KMainWindow would have to read kwinrc settings, plus same issue again: KMainWindow & KWin related "solution" only

ad 4)
Possible, but will cause visible flicker (user sees the window mapped with original size and then resized) - we might hide that in the compositor, but that would delay all window showing and be a KWin only solution again.

ad 5)
proposed solution =)
This is acceptable if users rather care about the size in relation to the window than to the screen ("window shall open at size that I left behind, no matter on which screen") and we can assume WMs to keep windows in workarea bounds (like KWin does and a diminished issue to to the changed handling of maximized windows, see next)


"Unfortunately" that fix trapped me into bug #317760 on steroids.
So far the maximization state was stored by storing "screenSize + 1", what, for the change and a multiscreen setup like [1024x768+0+0; 1920x1200+1024+0] means that the (formerly maximized on the XGA screen) window was restored to 2944+1200, what KWin would thankfully punch into 1920x1200 and place it on the WUXGA screen, so this approach had to go.

Using "screenSize(n) + 1" was equally not an option since that size could no longer be reliably matched against anything (the size was read from the combined screen size and chacking the available screens could fail because a window could legally be closed at 1025x769 on the WUXGA screen)

The cleanest option would have been to store the state in an additional key (see bug #51571, laptop + Tv became more popular since than, I guess) but due to the kdelibs semi(?)-frozen state i simply used the sign for this purpose.
-> One word and there'll be an extra key (wile unless anything else reads this, the negative values are pretty "safe")

Since the size is no longer used to store the state, it was possible to just preserve the unmaximized size and restore it alongside the maximization state.

And since the "maximized is screenSize + 1" kludge is gone in KMainWindow, we could remove it from KWin in addition.

Thank you for reading until this point ;-)


Diffs
-----

  kdeui/widgets/kmainwindow.cpp 85beacc 

Diff: http://git.reviewboard.kde.org/r/114484/diff/


Testing
-------

KWin + Metacity; glib + unix event dispatcher.


Thanks,

Thomas Lübking

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20131215/828c8baf/attachment.htm>