Behaviour of "Show Desktop"

Fri May 8 14:07:41 UTC 2015

On Friday, May 08, 2015 10:19:25 Thomas Lübking wrote:
> NOTICE THAT YOU HAVE SPLIT THIS THREAD!
> The original mail went to kwin and plasmashell in copies.
> I've also added the usability list:
> 
> PLEASE EVERYONE ENSURE TO CC THE OTHER RECIPIENTS!
> 
> -----------------------
> 
> On Freitag, 8. Mai 2015 06:07:09 CEST, Sebastian Kügler wrote:
> 
> A Wall of Text
> 
> tl;dr (afaiu):
> "I want show desktop" to behave like "minimize all".

Well, more like this is the previous behaviour, and we replaced it by 
something that has a lot of cornercases.
> Just some technical remarks:
> ----------------------------
> 
> > and shortcuts. The effect is now more dashboard like, applications are 
> > visually not hidden anymore but stashed aside, and the panel is invisible.
> 
> To please clarify terminology: s/hidden/minimized/ (actually "iconified")
> They're neither "stashed" aside, that's the visual gimmick of a KWin effect

Right, but before, the effect would effectively hide these windows, right?

> > https://bugs.kde.org/show_bug.cgi?id=67406
> > The "fix" was to introduce a config option to keep windows in the
> > minimized
> > state when the showing desktop mode was exited by opening a new app.
> 
> Please notice that this was a *hidden* option (Lubos apparently wasn't too
> happy with it) - it was virtually not available for the majority of users
> over all the time.

Perhaps useful to exclude it from this discussion for our sanity's sake. :)

> > * when I enter showing desktop mode, then right-click on the wallpaper | 
> > Desktop Settings, the window isn't shown and I'm not exiting 
> > showing desktop mode
> 
> Techinically possible solutions:
> * mark windows that shall interact with the desktop (config dialogs) as
> transient for the desktop 
> * unconditionally keep all windows with the same
> exposed PID as the desktop on top of it 
> * unconditionally allow all windows
> with the same exposed PID as the desktop to raise above it (ie. they're, if
> present, initially below but can still be brought above)

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

> > * when I enter showing desktop mode on an empty desktop, then 
> > hit alt-tab, the 
> > panel becomes quickly visible, then hides again, but in this case,
> > alt-tab 
> > does not exit showing desktop mode
> 
> Not reproducible. Bug in the effect?
> Please use "xprop -root _NET_SHOWING_DESKTOP" to determine the state (you
> can eg. "sleep 20;" before to setup the condition in the next 20 seconds)

Seems like a bug indeed. xprop show 1 and 0 correctly, so it must be "a bit 
deeper".

> > * when I enter showing desktop mode, say on desktop 1, then 
> > switch to virtual
> 
> Bug in the visual effect only
> https://git.reviewboard.kde.org/r/123636/
> 
> > Then, we have the problems that have to do with modality:
> > * when I enter showing desktop, I can't open a new application from the
> > app  launcher as the panel is not shown, this was possible before,
> > and also I think 
> > quite a common thing to do (again, has to do with the modality)
> 
> The "problem" is that this common behavior (show desktop and start a new
> application) is the source of https://bugs.kde.org/show_bug.cgi?id=67406

Yeah, well. As you said, the "fix" for this bug is an option, so this is not a 
problem of default behaviour. Here, I think it's fine to offer a plasmoid or 
kwin script to get that exact behaviour.

> > * in showing desktop mode, my primary means of switching applications is 
> > removed, this was working before, implementing as simply 
> > restored all windows 
> > and activated the app that was clicked on in the taskbar, with 
> > a config option to keep the other windows in their minimized state
> 
> Again: that config option was a secret.
> There's a publically available "minimize all" kwin script available for
> exactly /that/ behavior. It minimizes all windows on first and unminimizes
> exactly that list on second invocation and does not react on anything but
> its direct invocation (no implicit break of state)
> > Users need access to their desktops in order to interact with the next
> > application, open a file from the desktop.

This only affects the config option (which we leave aside for now). Point in 
case is: application interaction through the taskbar is impossible, that's a 
real and big regression in this feature.

> "Tidy up" was (and is) earlier provided via virtual desktops and is now
> officially available by minimizing all windows (a feature taken from
> windows which has this featuer because it traditionally has no virtual
> desktops)
> > But, when making it more modal, we have to find all these 
> > places to exit the mode and cancel it from there
> 
> "No" - we can actually simply break the state whenever the user activates
> any window. However see again https://bugs.kde.org/show_bug.cgi?id=67406
> and friends.

That "breaking" would be adding in "KWindowSystem::showingDesktop(false)" 
calls in the necessary places, or is there something else we need to do?

Cheers,
-- 
sebas

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