GNOME Bugzilla – Bug 651569
Allow to "hide" applications
Last modified: 2012-03-02 11:14:23 UTC
This is mainly a feature proposal to replace a commonly requested status icon functionality (GtkStatusIcon must die die die!). The first patch fixes a minor issue with workspace thumbnails: the placement of window previews suggests that a thumbnail is a miniature of the "real" workspace, but it still shows previews for minimized windows. It's minor given that minimizing is strongly discouraged, but still worth fixing even if we decide against the feature proposal. The second patch changes the behavior of the window picker to not show minimized windows - the intention is to redefine minimization as "hiding", e.g. as a replacement for notification area abuse. The last two patches can be seen as proposals of how to expose the functionality in the UI. See bug 651568 for a required mutter change.
Created attachment 188952 [details] [review] workspaceThumbnail: Handle minimized windows Workspace thumbnails are supposed to be miniatures of the "real" workspace they represent, but currently they show minimized windows like the window picker. Instead, hide minimized windows and track changes to update the thumbnail accordingly.
Created attachment 188953 [details] [review] workspace: Hide minimized windows While minimizing was still exposed in the interface, it made sense to show minimized windows in the window picker (as a de-facto window list replacement). Now with the minimized action gone from the default configuration, we are able to redefine the meaning of minimizing as "hiding", e.g. as a replacement for a common GtkStatusIcon functionality. So change the handling of minimized windows in the overview to not include them in the window picker.
Created attachment 188954 [details] [review] app-display: Add menu option to show/hide windows Allow hiding all windows of an application from the app icon's right-click menu. This functionality is commonly requested by users for long-running "background" applications (like music players, messaging apps, ...) and the primary reason for notification area abuse.
Created attachment 188955 [details] [review] app-menu: Add option to hide application Allow hiding the active application from the application menu. This functionality is commonly requested by users for long-running "background" applications (like music players, messaging apps, ...) and the primary reason for notification area abuse.
Review of attachment 188952 [details] [review]: This makes sense and the code looks good.
Comment on attachment 188952 [details] [review] workspaceThumbnail: Handle minimized windows Attachment 188952 [details] pushed as a34071e - workspaceThumbnail: Handle minimized windows Jon - we briefly discussed the hiding feature introduced by the remaining patches on IRC, and you were less than convinced that we'd want this. Can you add a quick comment here, so I can close the bug?
For the "hide" feature to work well, one more thing is needed: if you "hide" a window, it should not be associated with the workspace it was on when you hid it. Currently, if you minimize a window on workspace 3, the window is hidden but stays associated with workspace 3. Thus, even if there is no visible on this workspace anymore, it won't be removed from the workspace list. Also, if you then move to workspace 2 and click on the launcher icon to un-minimize (un-hide) the window, it will appear on workspace 3 instead of appearing on the current workspace (2). I think it's a bit confusing...
I like the ability to hide windows from applications that aren't being used but I think it would be better to have the function implemented in a way that doesn't require too much user management, like using the menus to hide them like the proposed patch or the current behavior of sending them to their own workspaces. For example, if I'm simply browsing the web I still want to keep Evolution and Rhythmbox running in the background so I can be notified of new mail or have a song playing in the background. My proposal work flow: 1) Launch Rhythmbox, start a playlist and close its window. 2) Launch Evolution, check for e-mail and close its window. 3) Launch Epiphany and get on with the task at hand (mindless web browsing :). To restore these applications the user would simply use the Dash or application browser, so the "bring the Rhythmbox window now so I can select a song" action is the same regardless of whether it's already running or not. This is unlike the old GNOME 2 setup, where the user would have to search three distinct places to find an app like Rhtymbox: the window list on the bottom panel, the notification area or the Applications menu.
*** Bug 656015 has been marked as a duplicate of this bug. ***
Was there a designer consensus on this?
As far as I can tell they didn't like it - I asked for a decision in comment #6, no real change since then; guess the bug can be closed WONTFIX.