Behaviour of "Show Desktop"

[Thomas Lübking]

On Freitag, 8. Mai 2015 16:07:41 CEST, Sebastian Kügler wrote:

>> PLEASE EVERYONE ENSURE TO CC THE OTHER RECIPIENTS!

Sebastian, what kind of crappy MUA do you use that sends multiple TOs instead of CCs? KMail bug? ;-)



> Well, more like this is the previous behaviour, and we replaced it by 
> something that has a lot of cornercases.

No, what you described involves the secrect ShowDesktopIsMinimizeAll config key. That is *not* the former behavior. It may have been the former behavior on your system, but that's irrelevant.
The key was known to a very limited amount of ppl. only.


> Right, but before, the effect would effectively hide these windows, right?
There was no special effect before. The windows were iconified ("minimized") and the configured minimization effect would catch them as a side effect.

But what I meant to say was that we should be strict on terminology here, because if we talk in generic terms (hidden) when meaning particular behavior (minimized), things will very soon get confusing.


> The next problem is clicking on a file on the desktop that opens an 
> application. The point is that we broke the interaction

The point is that either
a) this should break the state (show desktop is a very weak modal state)
b) this should just open the next window (show desktop is an action)
c) the state remains intact and no window shows up (strictly modal state)

and the point is that ppl. apparently want either a, b - and maybe (dashboard-thing) c.


>> Bug in the visual effect only
>> https://git.reviewboard.kde.org/r/123636/

> Yeah, well. As you said, the "fix" for this bug is an option

I said what where? The bug is a bug, the effect forgets to handle some windows. There's a patch and that does not involve any options.

> case is: application interaction through the taskbar is 
> impossible, that's a real and big regression in this feature.

That was and is actually the question being asked.
If (as seems crucial) the panel and thus the taskbar remain visible and enabled, the next step was to break the state w/ at least forceful activation of windows (clicking the taskbar)
If the taskbar is "good enough" in indicating the minimized state of windows and we somehow hint the showing desktop state, there should be no confusion (in breaking a modal state)

What I really do NOT want to do again is to cheat users with suggesting "showing desktop means to minimize all your windows" if it does not.
Either "show desktop" *is* just a "minimize all your windows" action or it must not cause that impression in any way.
That is not up for negotiation from at least my side.

> That "breaking" would be adding in "KWindowSystem::showingDesktop(false)" 
> calls in the necessary places, or is there something else we need to do?
Not inside kwin (do not call KWindowSystem from KWin, bad idea) but clients may break the state this way, yes.
However, this should no be necessary. Once the behavioral concept is determined, kwin can break the state in 99.9% of the required conditions itself.

Cheers,
Thomas