GNOME Bugzilla – Bug 162016
Provide extra show-desktop-related state to allow windows in 3 states simultaneously: minimized, hidden, and showing
Last modified: 2010-05-11 21:48:34 UTC
Case 1 ------ 1. Click "show desktop" applet button See: All currently open windows become "hidden" 2. Click "show desktop" See: Hidden windows return to visible Case 2 ------ 1. Click "show desktop" applet button See: All currently open windows become "hidden" 2. Open a new window See: Show desktop mode is implicitly disabled (without restoring hidden windows) 3. Click "show desktop" See: One new window is hidden There is a lot of history regarding the behavior of "show desktop" in this bugzilla, and in various mailing lists. I'll try to refer to all relevant information here. About the only uncontroversial thing is Case 1 above. Everyone seems to agree it works as it should, but there aren't any interesting use cases. With case 2, things start to get more complicated. The primary source of history in this system seems to be bug 92335. Some of that history is hard to read because there are many references to the "current" behavior without carefully specifying what that behavior actually is. From what I can tell from reading that history, at some point in the past, the following behavior existed: Case 3 ------ 1. Click "show desktop" applet button See: All currently open windows become "hidden" 2. Open a new window See: Show desktop mode is implicitly disabled and all hidden windows are made visible. The behavior in case 3 has some serious problems. Apparently it was impossible to rename a desktop item using "show desktop". Also, asynchronous events, (eg. popup windows), could cause the implicit disabling of "show desktop" in totally unexpected ways. The solution agreed upon in bug 92335 was to maintain the implicit disabling, but instead of restoring the windows to a visible state, transfering them instead to a minimized state. This change has not been carried out completely (as described in bug 162011). I contend that this was a solution to the wrong problem. Here's a use case that demonstrates a shortcoming of the current situation. Case 4 ------ 1. Press "print screen" 2. Click "save to desktop" 3. Double-click image to crop screenshot in the gimp At this point I'd like to be able to get all my windows back as they were at step 1, but there's no way to do this in one step. I contend that when "show desktop" mode is disabled, all hidden windows should be returned to a visible state. Nothing else will maintain consistency with state 1. The problem that should have been fixed for bug 92335 was the implicit disabling of "show desktop". That's the source of the confusion. But what to do when we're in "show desktop" mode and a new window gets mapped for some reason? There's an argument that at this point the system is in an inconsistent state and there's no good solution: http://lists.kde.org/?l=kde-usability&m=108274247022218&w=2 I disagree. I think the system is in a perfectly consistent state. Some windows are minimized (originally), some are hidden (due to "show desktop"), and some are visible due to subsequent operations. The source of all the confusion really stems from the fact that the there are not good visual cues for windows in the hidden state, (see bug 162010). Mac OS X solves this problem quite elegantly. There, the "show desktop" button slides all visible window off the screen so that just a sliver of each window is still visible. This is a visual indication that is totally distinct from a minimized window. The slivers also serve as a user-interaction point for disabling "show desktop" mode. Clicking on any sliver restores all the hidden windows. While windows are hidden, new windows can still be opened, and there is no implicit change to the state of the hidden windows. I won't argue that the visual indication and user-interface should necessarily match that of OS X. But there should be some sort of indication of hidden windows (distinct from minimized windows). Nothing but an explicit action should disable "show desktop" mode. And disabling "show desktop" mode should always restore all hidden windows to the state they had prior to "show desktop".
See also http://mail.gnome.org/archives/wm-spec-list/2004-August/msg00001.html, though you've linked to the most relevant parts already... :-) > I disagree. I think the system is in a perfectly consistent state. Some > windows are minimized (originally), some are hidden (due to "show desktop"), > and some are visible due to subsequent operations. You're misunderstanding. Due to the existing implementation and/or lack of extra ideas, there wasn't a way to have some windows minimized, some hidden, and some showing. You could have some minimized with all others hidden, or some minimized and none hidden. However, given your explanation and your specific example of how it could be accomplished (i.e. the Mac OS X behavior), I agree with you that your proposal is more consistent and removes negative surprises to end users. It may require EWMH changes.
I have a patch which allows the window states that Carl describes above.. "Some windows are minimized (originally), some are hidden (due to "show desktop"), and some are visible due to subsequent operations." It makes the "showing desktop" mode toggle always be explicit. It removes the behavior of implicitly toggling show desktop mode off, and minimizing all other windows when a new window is opened. Windows which are opened subsequent to turning showing desktop mode on are "immune" to the hidden state until showing desktop is turned back off. This allows for some really nice use cases which are impossible with the current behavior (implicitly disabling show desktop mode, and minimizing all other windows). The patch allows for the following behavior: Case 4 ------ 1. Click "show desktop" applet button See: All currently open windows become "hidden" 2. Open a new window See: Show desktop mode remains on, but the new window is given immunity to it and stays visible. 3. Click "show desktop" applet button See: Original windows return in their original state, with the new window visible on top. I believe this is in line with what Carl was suggesting. However, I think this solution may make the "visual" problem he was describing even more urgent. Namely, with the Show Desktop mode toggle becoming completely explicit, it is even more relevant that there is no visual indication that you are in that mode. Hidden windows appear no different that minimized ones, and they show up in the task switcher as well. As this patch leaves it, it is just not possible to switch to the windows - because they remain hidden even if you select them. I see 3 possible solutions to this, though I'm not sure which would be best - so I've left the patch as is. The possibilities I see are: 1) When a hidden window is activated, give that window immunity just as you would a newly opened window. 2) When a hidden window is activated, snap them out of show desktop mode. This would require some kind of visual cues to make it work - perhaps in a way comparable to the Mac OS X solution Carl describes. 3) Provide strong visual cues that you are in show desktop mode, and make it obvious why one cannot switch to these hidden windows. e.g. make them not visible in the task switcher
Created attachment 37594 [details] [review] patch which makes show desktop mode toggle alway explicit, and allows subsequently opened windows to be visible
Thanks for the work. Three points: (1) Please use the -p option to diff when creating patches for review (2) This option you propose has been suggested before (with the first of the three options you list for activating hidden windows, I believe). I can't find it in Gnome bugzilla with a quick search but note that it's option 3 at http://lists.kde.org/?l=kde-usability&m=108274247022218&w=2, which was also discussed at http://mail.gnome.org/archives/wm-spec-list/2004-August/msg00001.html. Note that the behavior you propose is what KDE used to do but intentionally changed to match current Gnome behavior after considering the options (3) I don't think this matches Carl's suggestion. It puts the desktop in an inconsistent state--there's a show desktop button which looks activated, but the desktop isn't showing. If the user wants to show the desktop, they have to press the button twice; once to "unshow" the desktop, then again to show it. I'm of the opinion that if we want to change anything, then we need three states with obvious ways to let the user know which windows are in which states (e.g. minimized are put in the tasklist, hidden are shoved to the sides of the screen, and showing are visible on the desktop)--i.e. what I believe Carl's suggestion is. Then, we'd have to worry about how to make an applet with more than just two states. But, of course, Havoc will need to weigh in here on what he wants done...
Thanks for reviewing and your comments. >I don't think this matches Carl's suggestion. It puts the desktop in an >inconsistent state--there's a show desktop button which looks activated, but the > desktop isn't showing. At the very least it probably does make the term "Showing Desktop" a misnomer... >If the user wants to show the desktop, they have to >press the button twice; once to "unshow" the desktop, then again to show it. I actually found this to feel pretty natural.. but I see how the point could be argued. This seems to me to be the obvious way it would work with a 3-state system with explicit-only "show desktop" mode change. Although, the toggle would be better named something like "Hide All Open Windows"/"Show Hidden Windows"... which probably means we are not implementing NET_SHOWING_DESKTOP at all anymore. > I'm of the opinion that if we want to change anything, then we need three states > with obvious ways to let the user know which windows are in which states (e.g. > minimized are put in the tasklist, hidden are shoved to the sides of the screen, > and showing are visible on the desktop)--i.e. what I believe Carl's suggestion > is. I think you've pretty well convinced me :). Just to take a step back though, from a use case perspective, with the current implicit unshow desktop mode and minimize-all-others behavior, it renders my most common use case impossible, and so as I result I never use the button. I've heard ancedotal stories of other users feeling the same. I normally want to open some spatial nautilus windows, do some drag and drop, or open a single file, but then go right back to the state I had, perhaps with one of the windows I opened now on top. The sad alternative I use now is I navigate around my virtual workspaces looking for one that doesn't have anything covering the part of the desktop I need. What do you think of the following alternative model? * Create three states for windows: Showing, Hidden, or Minimized. * Forget the concept of Show Desktop. Instead have a "Hide All Open Windows" button and a "Show All Hidden Windows" button.) * Hidden windows are pushed to the very edge of screen such that the entire desktop is effectively available. (Maybe there is some other innovative idea here for how the hidden windows could be displayed?) * Minimized windows are in the tasklist. Minimized windows are not affected by the "Hide All Open Windows" button, and so a minimized window will always become visible when it is unminimized. * On the "Show All Hidden Windows" event, hidden windows are returned to their original state, but behind any new windows which were opened subsequent to the hiding. (Is it possible to unhide a single hidden window without unhiding all of them? Can you click the window sliver to show all hidden windows? Or would this just show that particular window?)
Yes, I agree there's problems for some use cases with the current way we implement show desktop. I also believe there are problems for alternate use cases with your method and most other previous suggestions. I think that's part of why we discussed things on wm-spec-list, because there were just inherent problems with any choice we made. I think the alternative model you list looks reasonable (though it'd be great to come up with a couple different methods for hiding and experiment with them), but Havoc should really be the one commenting here...
"showing desktop" by pushing windows off the screen sounds basically reasonable to me, though I predict an animation of them flying off to the screen edges is required for the UI to work. The animation could just use the real windows (just move the windows incrementally) _NET_SHOWING_DESKTOP would not work here, though I think we might want to map it to our new approach somehow for back compat.
Another, less resource-hungry effect might be to have the window contents disappear and just leave some sort of outline of their borders behind-- fancier machines could implement a 'fade out' effect for the window contents, clapped-out old laptops could just have them disappear :)
Comment on attachment 37594 [details] [review] patch which makes show desktop mode toggle alway explicit, and allows subsequently opened windows to be visible As discussed above, this isn't the route we want to take. We'd rather go with something like the alternative model you discuss.
You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you please check again if the issue you reported here still happens in a recent version and update this report by adding a comment and adjusting the 'Version' field? Again thank you for reporting this and sorry that it could not be fixed for the version you originally used here. Set to NEEDINFO, so without feedback this report will be closed as INCOMPLETE after 6 weeks.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!