Behaviour of "Show Desktop"

[Thomas Lübking]

On Freitag, 8. Mai 2015 10:40:38 CEST, Marco Martin wrote:

> with a) the problem is that is a surprising behavior for many, as br tell.
> with b) then is very hard to even understand in what "state" we 
> are anymore, 
> and what would happen when the effect is disabled?

That's pretty much  the bottom of it - _NET_SHOWING_DESKTOP is defined as a state but users apparently are either seeking or mistaking it for an action.

My demand would be to make it "either or", ie. either it's a state that you get into and out of (and that is somehow sold visually) XOR it's an action, ie. whenever "set" we minimize all windows, remove the state immediately and forget about it.
No halfbreed and I do want to stop cheating users (ie. if a state, we do not suggest that all windows are just minimized)

The downside of the latter ("efficiently click all minimize buttons") is that degenerating a state into an action somehow "wastes" the feature.
"If you want a clean desktop to continue work, simply switch to another VD" =)


On Freitag, 8. Mai 2015 12:40:52 CEST, Marco Martin wrote:

> for show desktop applet and hot corners, using the minimize all 
> script, that even if we well know it has issues

What issues in particular?

> to summarise, what i gather would be needed is:
> * windows are hidden with something else than the minimize 
> attribute, in order to not lose it
> * when a new window appears, that something else does not get 
> applied, and the  window is visible
> * when a window gets activated trough taskbar or alt+tab, that 
> something else  gets removed and the window gets visible
> * when the effect gets disabled, all windows go visible, but 
> not all, since the minimized/not minimized state stays exactly as it
> was before the effect was applied


That is precisely how the minimize all script works atm (just that it minimizes windows to hide them and keeps track of what it has hidden internally)

From the recent discussions, though, I'm not even sure whether ppl. want that.
Notice that a problem with "letting windows through" without breaking the state implicitly is that the behavior of the next invocation may not act as expected.
Let's say you clicked a "show desktop button" that acts as suggested above:
All windows disappear, you open kickoff, launch openbox, maximize it, write a letter, then figure you want to change your wallpaper and click the "show desktop button" again: instead of seeing the desktop, all windows that were hidden before re-appear ...



The recent descriptions of usecases to have "show desktop" simply tidy it up, make me believe that we'll require two distinct features:

a) a dumb (dumber than present) "minimize all" (script) that really just minimizes all windows (and is just a nod to ppl. who find virtual desktops "confusing" ;-) - every other action would *not* cause a "mess" out of this.
This should pot. reside (as copy?) in plasmoids, because you can neither rely on a script being loaded nor even that KWin is the WM.

b) a *very* modal "showing_desktop" state that does *not* implicitly break (you've to exit it or alt+tab out of it - forcefull window activation through eg. the taskbar may break it in analogy to the tabbox) and lets you interact with the desktop and related windows (for simplicity: all windows in the desktop group, ie. same PID or transients) "undisturbed". Most notably, starting an application would NOT break the state and its windows would NOT appear (because we cannot reliably say what caused the window to show up).
Runners may still break the state on explicit invocation (because its an exported state, open to everyone to be set/withdrawn), but that's the runners problem.

Cheers,
Thomas