[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 8:19:25
Message-ID: 03ce3181-a38f-4719-a9fd-e96bceca576e () gmail ! com
[Download RAW message or body]

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



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


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

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

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

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

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

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

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]