[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: Behaviour of "Show Desktop"
From:       Thomas_Lübking <thomas.luebking () gmail ! com>
Date:       2015-05-08 12:21:47
Message-ID: 9ef9bf34-5077-4223-96f6-48f811260ca0 () gmail ! com
[Download RAW message or body]

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
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin


[prev in list] [next in list] [prev in thread] [next in thread]