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