----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114484/#review61957 -----------------------------------------------------------
I cringe at the negative-values hack, please make it an extra key. - David Faure On Dec. 16, 2013, 1:57 p.m., Thomas Lübking wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/114484/ > ----------------------------------------------------------- > > (Updated Dec. 16, 2013, 1:57 p.m.) > > > Review request for kdelibs, Àlex Fiestas, 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: https://git.reviewboard.kde.org/r/114484/diff/ > > > Testing > ------- > > KWin + Metacity; glib + unix event dispatcher. > > > Thanks, > > Thomas Lübking > >
