Review Request 123783: Adjust showing desktop behavior
Thomas Pfeiffer
colomar at autistici.org
Mon May 18 19:05:34 UTC 2015
> On May 14, 2015, 11:23 p.m., Thomas Pfeiffer wrote:
> > > 1) The minimizability of windows is ignored. It's a cornercase, but the former behavior was a side-effect of the implementation. (At least I don't know a reason to keep them)
> >
> > Could you explain what minimizability of windows means, please?
> >
> > > 2) The state is broken with the activation of windows, not them becoming visible. Latter doesn't work for most cases (unminimizing) for obvious reasons (they're not minimized ;-) and when a new window is mapped, the focus stealing prevention seems a good filter (if it's not good enough to gain the focus, it's not good enough to break the state either ;-)
> >
> > Sounds sensible
> >
> > > 3) Keep above windows remain visible and do not break the state (as if they'd belong to the desktop) for a request by the HIG group. I'm frankly not sure about the background of this behavior (hopefully not krunner - that doesn't work)
> >
> > The reasoning behind that was the assumption that keepabove is used for windows that one always wants to see (e.g. because they contain some information one is monitoring). We have no data to back that assumption up, though, so please challenge it if you have reason to believe that keepabove is mostly used for windows which do not have to be always visible. Our words are not gospel, after all ;)
> >
> > > 4) Windows in the desktop group initially remain above the desktop and can be activated w/ breaking the state, but can also hide behind the desktop (notably when that is clicked/activated)
> >
> > I'm not sure if I understood this correctly. My interpretation is this:
> > * If I open a window that is related to the desktop and *then* activate Show Desktop, the window gets hidden
> > * If I then activate the hidden window, it brakes the state
> > * If I activate Show Desktop and *then* open a window that is related to the desktop, it gets shown without braking the state
> >
> > Is that correct? If so, sounds good to me!
>
> Thomas Lübking wrote:
> > Could you explain what minimizability of windows means, please?
>
> Believe it or not, but windows can hint to be not minimizable (what KWin boldly ignores) and KWin has a rule to control that (you can specify that a particular window cannot be minimized)
> It's a corner case ;-)
>
> > that one always wants to see
>
> In doubt, we'd meanwhile have an "on screen display" layer which is even above the fullscreen layer.
> The question is whether this context (showing desktop) is similar to eg. running a fullscreen game or video. Both would overlay even keep above windows.
>
> I'm not afraid of another field test, though >-)
>
> > I'm not sure if I understood this correctly.
>
> Second part: yes, first part: no.
> Basically they behave like keep above windows. They initially remain visible. If you click (activate/raise) the desktop, they'll go behind, if you then reactivate them (through the taskbar or eg. the desktop RMB menu), they'll show up WITHOUT breaking the state.
>
> I'm agnostic to whether they should be initially hidden, but would object having them break the state depending on whether they were visible while entering the state.
>
> 1st because it makes the code more complex ;-)
>
> 2nd because "visible" is relative in this context: they're neither keep above (so could have been behind a maximized window) nor on all virtual desktops (so could have been on such)
> They could even have randomly been occluded by three other windows.
>
> In return the assumed usecase "show desktop -> change wallpaper" would "randomly" turn into "show desktop -> restore all windows -> change wallpaper"
Sorry for not replying earlier :(
> Believe it or not, but windows can hint to be not minimizable (what KWin boldly ignores) and KWin has a rule to control that (you can specify that a particular window cannot be minimized)
It's a corner case ;-)
I assume non-minimizable windows are things like modal dialogs where someone at Microsoft (or Xerox or... I dunno) once had the bright idea that they should not have a minimize button. Those windows are not supposed to stay open for long anyway, so yes, corner case which does not deserve much attention (e.g. just treating them like any other window is fine).
> I'm not afraid of another field test, though >-)
Yeah, let's see what happens ;)
> Second part: yes, first part: no.
Basically they behave like keep above windows. They initially remain visible. If you click (activate/raise) the desktop, they'll go behind, if you then reactivate them (through the taskbar or eg. the desktop RMB menu), they'll show up WITHOUT breaking the state.
Ah okay. Yes, that is fine, too (better, probably).
So yes, green light from my side as well!
- Thomas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123783/#review80368
-----------------------------------------------------------
On May 13, 2015, 10:21 p.m., Thomas Lübking wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123783/
> -----------------------------------------------------------
>
> (Updated May 13, 2015, 10:21 p.m.)
>
>
> Review request for kwin, Plasma, Kai Uwe Broulik, David Edmundson, Martin Gräßlin, Marco Martin, Sebastian Kügler, and Thomas Pfeiffer.
>
>
> Bugs: 346837, 346933 and 347212
> https://bugs.kde.org/show_bug.cgi?id=346837
> https://bugs.kde.org/show_bug.cgi?id=346933
> https://bugs.kde.org/show_bug.cgi?id=347212
>
>
> Repository: kwin
>
>
> Description
> -------
>
> Errhemmmm... while we're waiting for final comments of the HIG group ;-)
> Here's a patch that *mostly* restores the 5.2 behavior
>
> Notable differences:
>
> 1) The minimizability of windows is ignored. It's a cornercase, but the former behavior was a side-effect of the implementation. (At least I don't know a reason to keep them)
>
> 2) The state is broken with the *activation* of windows, not them becoming visible. Latter doesn't work for most cases (unminimizing) for obvious reasons (they're not minimized ;-) and when a new window is mapped, the focus stealing prevention seems a good filter (if it's not good enough to gain the focus, it's not good enough to break the state either ;-)
>
> 3) Keep above windows remain visible and do not break the state (as if they'd belong to the desktop) for a request by the HIG group. I'm frankly not sure about the background of this behavior (hopefully not krunner - that doesn't work)
>
> 4) Windows in the desktop group initially remain above the desktop and can be activated w/ breaking the state, but can also hide behind the desktop (notably when that is clicked/activated)
>
>
> Diffs
> -----
>
> activation.cpp fe0a51f
> client.h 40d503c
> client.cpp a6fbf3e
> layers.cpp b6d5b75
> manage.cpp 75af4e5
> workspace.cpp 09ae9a2
>
> Diff: https://git.reviewboard.kde.org/r/123783/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Thomas Lübking
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150518/2898e501/attachment-0001.html>
More information about the Plasma-devel
mailing list