Review Request 123783: Adjust showing desktop behavior

[Thomas Pfeiffer]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123783/#review80368
-----------------------------------------------------------


> 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 Pfeiffer


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/20150514/a6cb2be4/attachment-0001.html>