When "Show Desktop" option is enabled in the Task Switcher part of Kwin settings, it displays desktop as one of the options to switch to, in addition to other open windows. If you invoke it once, the desktop is shown, but if you invoke it again (with the desktop still visible) it hides the desktop. when enabled in task switcher, actually 'toggles' desktop visibility Reproducible: Always Expected Results: If the desktop option from the task switcher is selected again, with the desktop already being shown, no action should be taken.
"when enabled in task switcher, actually 'toggles' desktop visibility" in the description may be ignored. Sorry for not verifying before posting. Thanks.
I agree that - the option might better be "Include 'toggle desktop visibility' icon" - the label should correctly indicate "show desktop" and "hide desktop" - the feature itself maybe questionable (the desktop showing state has nothing to do with windows switching, that's some sort of windows disease, I assume?) But the actual behavior follows the in == out paradigma - I would not consider that a bug. Notably since activating another window (by the tabbox or otherwise) will *not* reverse the "showing desktop" state. By disabling (or rather removing) the "window", the user could get himself into a state that s/he cannot leave the same way - I'd rather consider that an UX issue.
In my opinion, the option should, if ever, be to show (switch to) desktop (in order to be consistent) and treat the desktop merely as a window. This would be in line with the Windows implementation too; and hence what a 'new' user might expect. If the above is not to be, I'd say that the option to toggle desktop visibility in tab switcher seems weird to me. It's still only *my* opinion though and I'm *nothing* (in respect of development effort towards kwin in particular and kde in general) Thanks
(In reply to Thomas Lübking from comment #2) > I agree that > - the option might better be "Include 'toggle desktop visibility' icon" > - the label should correctly indicate "show desktop" and "hide desktop" > - the feature itself maybe questionable (the desktop showing state has > nothing to do with windows switching, that's some sort of windows disease, I > assume?) Here we are in the "precise vs. correct" debate again. Of course, from a technical POV, it makes zero sense to insert the desktop in a row of windows, because they're two completely different things. That's not what users care about, though. What counts for them is whether it is _useful_ to have such a thing. And from a user perspective, it does make sense to treat the desktop just like any other window, because it actually isn't all that different from a user perspective: It's a container with information and some interactive elements in it. Anf for that reason, I agree with Yogesh that it should also behave the same, meaning: If I switch to desktop, it moves to the front. If I switch to a window, that window overlays the desktop again. When I switch back to desktop, the desktop gets "raised" again. What we could think about, though, is to show the widget dashboard instead of the "show desktop" function (which in fact doesn't raise the desktop but hides all windows), because that's likely what users want to interact with temporarily. Would that give you less of a headache?
> If I switch to a window, that window overlays the desktop again. When I switch back to > desktop, the desktop gets "raised" again. That is actually what happens. The reporters concern is about the behavior "when you switch from the desktop to the desktop" The thing acts as toggle, ie. when you're in ShowDesktop mode, the next invocation will restore all windows. If this was -as suggested- turned NOOP, the user would have to know - a shortcut - a desktop action (double click etc.) - about newly mapped windows implicitly breaking the ShowDesktop state to get out of this mode (restore all windows at once) That's why I believe the present in == out behavior is indeed sane. ------ The dektop is somehow a fullscreen keep below below [sic] window, which can be activated as any other window (given the actual desktop does not deny the focus or it's enforced by a rule) So the "in-line" behavior would be to activate and bring the dektop to front IN ITS LAYER (ie. usually keep it where it is ;-) The plasma-active shell had a different approach and the desktop was an "ordinary" window, which could be freely positioned in the normal layer stack (all the time) Also, following the "show desktop" implementation, the entire thing would behave fundamentally different - notably regarding all other windows (which, as you pointed out, are minimized, what is indicated everywhere else around the desktop, like eg. in the taskbar) and in return to what happens on invoking the "show dektop" feature otherwise, resp. "accidentally" breaking it by showing a window (what will cause all windows to "raise" again) So if the goal was to have the desktop entry in the tabbox allow the user to activate and raise the desktop as if it was a normal window, this is probably what should happen technically as well. The challenge of such approach would be "how to get out of this mode" (ie. the desktop back into the desktop layer) - unless eg. implicitly on loosing focus (what turns it into a "show destkop" toggle)
Hence the idea to use the dashboard mode instead of show desktop for the tab switcher. Would that be less problematic?
The dashboard is a proprietary feature, it's availability is not exposed, nor is there a specified trigger. (Ie. it's an option, but this must change before) Also, afaiu, the dashboard is no longer an individual widget set in Plasma5 anyway - so there seems little difference in just toggling the desktop (except maybe visually) That however does not address this bug: How should a second invocation of the dashboard toggle be handled? Any answer to this more or less applies to "show desktop" (which is really just a different way to show the dashboard - there's no rule to iplement this by minimizing other windows and raising the desktop is even an alternative suggestion in the NETWM spec) as well. => One could eg. hide the dashboard ("unshow" the desktop) when even just invoking the tabbox (and re-show dashboard/desktop on explicit selection from the tabbox again)?
I just checked on a certain proprietary operating system which this feature may or may not have been inspired by and found that they do it exactly the way we're currently doing it. So at least we won't have to fear that users coming form that OS may be confused by our implementation if we leave it as it is. As for the labels: I see two possible routes here: 1. We could go the regular user perspective road and just call it "Desktop" (which would match a user's mental model of treating the desktop "sort of like a window") in the list (this is also what that other OS does) and label the checkbox "Include Desktop"- 2. We could go the precise route by calling it "Minimize All Windows" and "Restore Windows" (depending on the state) and label the checkbox "Include 'minimize/restore windows' icon". Whit I dislike about "desktop visibility" and "show/hide desktop" is that the desktop isn't really "hidden" when the windows are restored unless it's completely covered by windows. We should keep the discussion about how to best implement "Show Desktop" in mind though, as I think we could do better than that other OS here.
(In reply to Thomas Pfeiffer from comment #8) > 1. We could go the regular user perspective road and just call it "Desktop" > (which would match a user's mental model of treating the desktop "sort of > like a window") in the list (this is also what that other OS does) and label > the checkbox "Include Desktop"- +1 > 2. We could go the precise route by calling it "Minimize All Windows" and > "Restore Windows" (depending on the state) and label the checkbox "Include > 'minimize/restore windows' icon". wohoahooo.... no. ;-) There's a supersecret key to make showDesktop behave like minimize all - what it is not (meant to be) - after Lubos gave into a flamewar bug (that re-occurred afterwards). We won't label that minimize all and it is not minmize all and let's please not talk about this again ;-) > We should keep the discussion about how to best implement "Show Desktop" in > mind though, as I think we could do better than that other OS here. @Martin (and others) Proposal: a) add dedicated (shortcut or rather script for) a minimize all feature b) scratch the supersecret key c) implement show desktop by simply raising the desktop into the dock layer [1] (preventing all "this minimizes because they're minimized in the taskbar" confusion) d) break the showdesktop mode w/ tabbox invocation (aside the present causes) [1] @Martin (and anyone who can follow ;-) dock == keepabove, while the desktop is active no fullscreen window can be active, thus in the fullscreen layer. Docks/Panels (currently do no affect the show desktop state) can still raise above the dock layered desktop, as well as notifications/OSD Caveat: krunner - is it still a dock (in all cases)? or at least keepabove?
> a) add dedicated (shortcut or rather script for) a minimize all feature rather script > b) scratch the supersecret key +1 > c) implement show desktop by simply raising the desktop into the dock layer [1] (preventing all "this minimizes because they're minimized in the taskbar" confusion) This could be morphed together with the "dashboard" feature. If this is the way to do it, I do not see a need for dashboard any more. Adding Marco because of that ;-) > d) break the showdesktop mode w/ tabbox invocation (aside the present causes) +1 and probably break it in even more conditions (PW, DG?)
(In reply to Martin Gräßlin from comment #10) > rather script will do before any push ;-) > > b) scratch the supersecret key > +1 done > > c) implement show desktop by simply raising the desktop into the dock layer [1] (preventing all "this minimizes because they're minimized in the taskbar" confusion) Done, respl. am playing around. Actually we keep a keepabove > dock, so putting it into the dock would keep keepaboves visible. Putting it into the keepabove will _allow_ it to be above keepaboves, but hides panels (more dashboard-a-like?) => We'll likely have to forge a krunner patch (eg. to get it into a group w/ plasmashell and have it be keepabove so that it can be shown w/o breaking the state?!) > > d) break the showdesktop mode w/ tabbox invocation (aside the present causes) > +1 and probably break it in even more conditions (PW, DG?) done, done & done (latter two become very required by the raising approach since otherwise the windows are stashed unless elevated on hover - it's also better than requiring the effects to be configured to show minmized windows to show anything while showing the desktop)
Git commit 0b6a804701b3df31df42660444d37426cebb2293 by Thomas Lübking. Committed on 07/04/2015 at 21:59. Pushed by luebking into branch 'master'. break showingDesktop w/ tabbox/PW/DG This is now crucial, because while before (the minimized) windows were conditionally shown, but are now always behind the desktop. Also, it makes the tabbox more consistent. REVIEW: 122679 M +5 -3 effects/desktopgrid/desktopgrid.cpp M +1 -0 effects/presentwindows/presentwindows.cpp M +1 -0 tabbox/tabbox.cpp http://commits.kde.org/kwin/0b6a804701b3df31df42660444d37426cebb2293