[HIG] Behaviour of "Show Desktop" - Usability DECISION required

[Thomas Lübking]

On Samstag, 9. Mai 2015 14:59:38 CEST, Sebastian Kügler wrote:

> Your email client doesn't line break, I have a wide-screen 
> monitor. What kind of crappy MUA are you using? (Muahaha, well played, Sir!)

outdated trojita affected by https://bugs.kde.org/337919 & 
https://bugs.kde.org/show_bug.cgi?id=321462


> What's important from my side is that we do not disturb 
> existing workflows of  the default behaviour, we have to keep that in place.
> (See wall of text email for details.)
> The implementation, I don't care so much about as long as we can 
> free it from bugs in time for the next stable update.

Ok, since members of the HIG team previously asked for some behavior that 
deviates from the exact former one, also we've some more flexibility - so 
let's determine some cases first.

1. Keep Above windows (most prominently: yakuake)
----------------------
a) treat like "normal" windows (vanish, their activation breaks the state)
b) unconditionally keep visible (their activation leaves the state intact)
c) interchangeable with desktop (they go above and below the desktop 
depending on the active window - does oc. not break the state)

2. Windows that "belong to the desktop" (same PID, eg. wallpaper dialog)
---------------------------------------
a) unconditionally keep visible (their activation leaves the state intact)
b) treat like "normal" windows (vanish, their activation breaks the state)
c) interchangeable with desktop (they go above and below the desktop 
depending on the active window - does oc. not break the state)

3. Unminimizable windows (real cornercase, but can be forbidden)
------------------------
a) unconditionally keep visible (their activation leaves the state intact)
b) treat like "normal" windows (vanish, their activation breaks the state)
c) interchangeable with desktop (they go above and below the desktop 
depending on the active window - does oc. not break the state)

4. Splash screens
-----------------
a) their showing-up breaks the state
b) ignore them

5. Break condition
-------------------
a) mapping + activation (mapping = "whenever a window is brought to 
screen")
b) activation only (ie. the focus stealing prevention would also prevent 
breakage. In case of "extreme" -the default is "low"- that implies only 
explicit/forceful activation, eg. throught the taskbar, will break the 
desktop showing)
c) forceful activation only (NOTICE: that this would break the pot. usecase 
to show the desktop to click a file on it to have it opened, resp. that 
opening would be stashed until the state is broken - unless the desktop 
breaks the state itself on this occasion)


The answer to the above items used to be "a"
In case you answered "c", you may also define the initial behavior (ie. eg. 
if you've only the wallpaper config dialog and press the "show desktop" 
button, you likely want it to disappear at first, but if you entered the 
mode and called it from the RMB menu, you do not necessarily want to break 
the state to see it?


6. Krunner
----------
There's a long standing complaint about krunner breaking the mode. The KDE3 
runner used to be part of the desktop group, but krunner became a process 
of its own and was not moved into the desktop group by WM hints.
KWin will *not* try to detect krunner, but the latter could be set 
transient for the desktop. Transient windows are in their main windows 
group (thus did not get hidden nor break the state before) and are 
naturally above them (that's the point of a transient ;-)



Cheers,
Thomas

---
ccbbb-transient