GNOME Bugzilla – Bug 81222
Figure out the common usage modes (see comment 14)
Last modified: 2018-01-24 13:12:48 UTC
When I iconify a window it won't show in the task-list of another workspace. I would expect the option 'restoring minimized windows' with the setting 'Restore to current workspace' to have this behaviour. If the setting 'restore to native workspace' is selected it could be the behaviour it has now, to only show iconified windows in the task-list on the workspace where it was iconified. See also bug #80951 for my comments on how I use this feature together with what is described in that bug-report.
Oops I meant bug #79500 instead of #80951
Here the one-liner fix to implement this behaviour : diff -ru libwnck-0.9-orig/libwnck/tasklist.c libwnck-0.9/libwnck/tasklist.c --- libwnck-0.9-orig/libwnck/tasklist.c Thu May 9 17:45:39 2002 +++ libwnck-0.9/libwnck/tasklist.c Thu May 9 17:57:50 2002 @@ -1067,7 +1067,9 @@ state = wnck_window_get_state (win); if ((state & WNCK_WINDOW_STATE_SKIP_TASKLIST) == 0 && - (tasklist->priv->include_all_workspaces || + ((tasklist->priv->switch_workspace_on_unminimize && + (state & WNCK_WINDOW_STATE_MINIMIZED)) || + tasklist->priv->include_all_workspaces || active_workspace == NULL || wnck_window_is_on_workspace (win, active_workspace))) {
I leave it up to someone else to integrate this fix into cvs, and set the status of this bug-report to FIXED. BTW this patch is against libwnck-0.9 With this fix the minimized windows are allways show in the task-list if the preference 'restore to current workspace' is set. If this preference is set to 'restore to native workspace' it only shows the minized windows for the workspace where the window was minimized. BTW2 This makes me very happy since it is my first bug-fix I sent in for gnome. :-) (I have been lurking for far too long)
Reassigning to libwnck. Havoc: is this bug? feature? crack option?
I also have a patch in my inbox to add "show only minimized windows" as a setting. I guess it's true that "unminimize windows on current space" is only useful if you show minimized windows on all spaces. I'm a bit worried users will think it's a bug if they choose "show only windows on current workspace" and still get minimized windows from other spaces.
In my opinion the current settings are perfect as they are (version 1.0 of window-list) Adding an option to allways display minimized windows seems useless to me. Where is the option "show only windows on current desktop"?
The "only display minimized windows" setting is intended to use the window list like traditional UNIX icons, i.e. the app is either an icon or a window but not both. The props dialog has "Show windows from current workspace"
Ah yes, how could I have missed it. :o/ I don't really grasp 'traditional Unix icons', you mean like it was in Win3.1 and its predessors? What would be the usefullness of this feature, and what does it have to do with the window-list? This seems something different then the issue this bug-report (and its fix) talks about.
What can I do to get this fix included into the development tree??
I think someone needs to step back and sort out the various ways the window list can be used and decide which make sense and adjust the prefs accordingly. I don't feel like I have a good grasp of it.
This is a good usability project for someone to think through.</hint>
Should mop up these settings for 2.2 see also #84411
For me it means having to move the mouse a shorter distance. It is faster to click a window/task in the window-list to minimize, click on another workspace in the workspace-switcher and click the minimized task in the Window-list to unminimize it. The current way is to find the corner of the window-involved and click open the menu and select the workspace. Off course the current way is faster with one window, but not with several. For instance when having several terminal-windows I want to move to a new work-space.
More detail on what this bug is blocking on, I sent someone the following in private mail: My comment in bugzilla is: I think someone needs to step back and sort out the various ways the window list can be used and decide which make sense and adjust the prefs accordingly. I don't feel like I have a good grasp of it. What I mean by that is: If we add more toggle buttons to the prefs, so we have N toggle buttons, then we have 2^N or something combinations of settings. What I want to know is, which of those combinations are useful. In other words, how many big picture different "usage modes" are there for the task list. This is an essential step to understanding how we could simplify or make more useful the settings, and to understanding why each usage mode is useful and whether we could create a usage mode combining the best of all worlds. It also allows us to understand whether the usage modes have interactions with other desktop GUI decisions (if so, then the usage modes are potentially going to cause problems, because then you have to make those other GUI decisions configurable also, and you get cascading combinatoric preferences hell). So basically, I would like someone to list: - all the settings that exist now - the various settings that have been proposed - enumerate each combination of those (possibly lumping some combinations together) - write down which combinations are useful "modes," and why, and which combinations are useless - from this see which settings are "standalone" and which interact to create "modes" of tasklist usage If we do this, I think we will understand the problem a bit better, and be in a position to guess at the pros and cons of adding each setting. I would not be surprised if it turns out that some of the settings we don't have are more useful than some of the ones we do have.
Has any work on integrating havoc's comments into the patch been done?
Retitling, to reflect what needs to be done first (and so when I reference this in other bugs it's more clear to others what I mean).
Bug 163135 had a different request which conflicts with both the patch in this bug and the "show only minimzed windows" one from bug 84411; it basically came from a (really strange, IMO) usage case where the window list was predominantly used for active windows only. ...just something else to keep in mind when writing up the usage modes.
Bug 163135 has been marked as a duplicate of bug 91655, which covers treatment of minimized windows in general.
This looks like it has been sitting around for a while, so I'll try to oblige Havoc Pennington's request... --- CHOICE: GROUPING Consider this following choice: - ALWAYS GROUP/NEVER GROUP/SOMETIMES GROUP windows in list in window list I think this should be streamlined by eliminating the "ALWAYS GROUP" option. The "SOMETIMES GROUP" option should Just Work. I think that either 1.) there will be enough room on the list to display all of the available windows, period, and it's pointless to group (but sorting by class would be very helpful) or 2.) there's not, and grouping should be turned on. On the Size tab of Window List preferences, users can specify the minimum and maximum size for individual window-buttons in the list (though it currently seems to be somewhat broken, and it seems the minimum refers to individual windows but the maximum to the list as a whole). The minimum size here should definitely trigger the grouping mechanism (it currently does not). Arguably, grouping should start even earlier if ungrouping would force any buttons to be smaller than their full titles. Personally, I wouldn't be sad if the NEVER GROUP option went away entirely, given how unusable the window list becomes when it gets crowded. Are there any advocates for keeping it? --- CHOICES: ICONS AND MINIMIZED ONLY - Show ICON ONLY/TEXT+ICON for open windows - Show ICON ONLY/TEXT+ICON for minimized windows - Show ALL/MINIMIZED windows in window list There is also the question of whether the text for minimized windows, if shown, should be bracketed, italicized, bolded, on a different background color, etc, which is entirely orthogonal and should be discussed under Bug 91655. For this set of choices, we can enumerate the following permutations: A.) Show all windows with text B.) Show minimized windows only, with text C.) Show all windows, icon only. D.) Show minimized windows only, icon only E.) Show open windows with text, minimized as icon only F.) Show open windows icon only, minimized with text A is what is currently hard-wired into Gnome, and is also the Windows default (if not also hard-wired). D is what MacOS X does, but the icons are actually thumbnails of the windows with the application icon superimposed in a corner. I think E is what joh@gmx.net is proposing. Some people don't seem to prefer to find their windows by icon-plus-tooltip, to save space. Other people seem to envision the window list as a place where only minimized windows should go, instead of a universal list. Given that, there's probably a reasonable market for both "minimized windows only" and "icons not text". Certain combinations (like say, F) might be quite rare, though. Those most concerned about Preference Proliferation would say that we should have only one option, and if so, I think that should be A. A reasonable compromise might be to say that A and D are polar opposites, with respect to space usage, and that those two and only those two should be allowed. This would probably make MacOS X fans happy. Doing minimized window thumbnails would certainly look cool and may help users find their windows faster, but it sounds technically involved and not particularly space-efficient. --- GROUPING/ICONIFICATION INTERACTION Note that icon-only entries, because they are so space-efficient, probably don't need to be grouped. So a scheme that only uses icons doesn't need to worry about grouping, which eliminates some permutations. For example, If we were to allow only A and D, we'd have A+GROUPING, A-NO_GROUPING, and D. An entirely different way of looking at the icon-only approach is as an alternative fallback to grouping. At a certain threshold of crowdedness, some or all windows would change from being text+icon to icon only. Fans of the icon-only approach could simply allocate a small area for the window list, and thus trigger iconification all or most of the time. This would leave the only preference as "When low on space: KEEP TITLES AND GROUP / ICONIFY". I don't think I like this idea very much. But perhaps we can settle on one or two Just Works compromises that would please almost everyone. --- CHOICES: MULTIPLE WORKSPACES The previous choices all involved desktops with only a single workspace. This last set encompasses the issues I think are uniquely related to multiple workspaces: - Restore windows to CURRENT/NATIVE workspace - Show windows from CURRENT/ALL workspaces - Show OPEN+MIN/MINIMIZED windows in window list Keep in mind that windows can always be moved across workspaces with the pull-down menu provided by the window manager (at least in Metacity here under Fedora Core 3), or by DnD inside the Workplace Switcher applet. Possibilities... 1.) Each workspace is completely isolated from all others. Workspace Switcher must be used to switch between them. Firm choice: - Show windows from CURRENT workspace only Not meaningful: - Restore windows to CURRENT/NATIVE workspace All other choices, including "Show OPEN+MIN/MINIMIZED windows in window list" essentially collapse to what has already been discussed. 2.) The window list operates as a universal holder for MINIMIZED windows only. Workspace Switcher must be used to switch workspaces. Choices: - Restore windows to CURRENT workspace - Show windows from ALL workspaces - Show MINIMIZED windows only in window list 3.) The window list is used to navigate workspaces but not move windows. Workspace Switcher is only needed when one wants to start a new application on a completely new workspace, but might be used at other times, too. Choices: - Show windows from ALL workspaces - Restore windows to NATIVE workspace * And jump to that workspace - Show OPEN+MIN windows in window list 4.) The window list is used to bring windows to the current workspace or to access any window in the current workspace. Workspace Switcher must be used to change workspaces. Choices: - Restore windows to CURRENT workspace - Show windows from ALL workspaces - Show OPEN+MIN windows in window list 5.) The window list shows all minimized applications, but when activated, they always return to their native workspace. Workspace Switcher must be used to switch workspaces. Choices: - Restore windows to NATIVE workspace - Show windows from ALL workspaces - Show MINIMIZED windows in window list -- I find 4 and especially 5 to be confused. 1 is quintessential and is the current default (for Fedora Core 3, at least). 2 is kinda neat. 3 makes sense. Personally, I don't use workspaces. If I did, I'd probably pick 1; maybe if I was constantly misplacing windows, I'd switch to 3. Novice users could easily become confused by multiple workspaces, especially given a default of 1, because they could end up in situations where they cannot see the window they are looking for, and don't know what to do to get it back. Workspaces are probably a handy feature for folks who have multiple domains of computer work or multiple threads of activity, though, so they should be available in one form or another, even if they are not set up by default. Note that the preferences about what windows to show in the window list and where un-minimized windows end up are accessed from the Window List applet, but all other workspace-related preferences are accessed from Workspace Switcher. This seems mildly confusing. One would think they should at least be cross-referenced. --- So, there you have it. (Hopefully I haven't missed any relevant cases.) I guess now we need to decide which permutations should be the default, which are supported alternatives, which are disallowed, and which might be allowed to sneak in as a side effect of allowing others, if any. Not sure if this is the sort of decision that is normally made on a UI mailing list, or after some formal usability testing, or what. -- Beland
Removing GNOME2.x target milestone for these bugs since this milestone hardly makes sense now.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libwnck/issues/7.