Behaviour of "Show Desktop"

[Sebastian Kügler]

On Friday, May 08, 2015 19:08:33 Thomas Lübking wrote:
> 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? ;-)

The venerable KMail, of course.

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!)

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

I guess I'm among them simply because I opened the code with the #ifdeffery 
more than once, lately. Let's quickly forget about that.

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

Aye.

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

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.

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

Okay, cool.

Thanks,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9