GNOME Bugzilla – Bug 661156
alt-tab: Ignore workspaces in popups
Last modified: 2013-04-03 17:14:30 UTC
I know I'll get flamed for this, but I've been testing this patch for a week now and it makes enough sense to me to put it up for discussion. Basically it feels weird to me to have a global list of all applications, but then base the switching behavior on the "location" of the active application. I understand that many people like to use workspaces to logically group windows together - I don't see how it fits in with an application-based switcher (as workspaces group windows, not applications), but I'm still aware of that usage. However, we don't actually group applications by workspace (which is pretty much impossible in my opinion, as a single application may have windows on more than one workspace) - we have some weird grouping by "on this" or "only on any other" workspace. I think the result does not work very well - neither for those who use workspaces as "task groups", nor for those that don't. In fact I'd argue that for the first group the application-based switcher is wrong to begin with - if the mental model is "windows per workspace", why group by applications at all? For the second group the workspace "mix-ins" make the behavior a lot more unpredictable and confusing. So my proposal here: remove all workspace logic from the switcher to make it purely application-based; if we don't want the "task-group" users to require an extension, we can add a windows-per-workspace switcher for them (either as a separate shortcut action or as an - uhm - option)
Created attachment 198510 [details] [review] alt-tab: Ignore workspaces in popups Currently both the app switcher and the thumbnail list divide items first into two groups (based on whether the item is located on the current workspace or not), and then sort each group individually by MRU. The resulting behavior is often confusing, e.g. when using alt-tab a second time does not switch back to the original window when the first invocation involved a workspace switch and the workspace contains windows of more than one application. Instead, make the behavior more predictable by sorting both lists strictly by MRU.
(In reply to comment #0) > I know I'll get flamed for this, but I've been testing this patch for a week > now and it makes enough sense to me to put it up for discussion. Basically it > feels weird to me to have a global list of all applications, but then base the > switching behavior on the "location" of the active application. I understand > that many people like to use workspaces to logically group windows together - I > don't see how it fits in with an application-based switcher (as workspaces > group windows, not applications), but I'm still aware of that usage. However, > we don't actually group applications by workspace (which is pretty much > impossible in my opinion, as a single application may have windows on more than > one workspace) - we have some weird grouping by "on this" or "only on any > other" workspace. I think the result does not work very well - neither for > those who use workspaces as "task groups", nor for those that don't. In fact > I'd argue that for the first group the application-based switcher is wrong to > begin with - if the mental model is "windows per workspace", why group by > applications at all? For the second group the workspace "mix-ins" make the > behavior a lot more unpredictable and confusing. > > So my proposal here: remove all workspace logic from the switcher to make it > purely application-based; if we don't want the "task-group" users to require an > extension, we can add a windows-per-workspace switcher for them (either as a > separate shortcut action or as an - uhm - option) As one of the "task-group" users I obviously don't really like that. I see your point for the applications, but for windows having the workspace separation makes isn't really confusing.
(In reply to comment #2) > I see your point for the applications, but for windows having the workspace > separation makes isn't really confusing. Yeah, it is less weird for windows (though I still think that you want a windows-per-workspace switcher).
(In reply to comment #3) > (In reply to comment #2) > > I see your point for the applications, but for windows having the workspace > > separation makes isn't really confusing. > > Yeah, it is less weird for windows (though I still think that you want a > windows-per-workspace switcher). Well it works by having "stuff I don't care about right now" at the end.
Mmmh, but is this still useful if we only do the workspace-grouping for windows? On the other hand, last time I saw the code of the existing alt-tab extension, it popped up a system-modal dialog at first run to pick one of several implementations ... *shudder*
I never thought adding the workspace separation of apps in the application switcher was a good idea. We don't have alternate views of the dash per workspace and I don't think it makes sense to morph the global application switcher by workspace either. The things that live in "spaces" are windows not apps. Having the window list component of the application switcher be different per workspace is at least more reasonable but I'm still not sure it is a good idea. The current behavior breaks motor memory of using the alt-tab to always go back to your last thing. And we've rightly gotten complaints about that. Workspaces are very useful - for organizing windows visually and spatially. The application switcher is unrelated to that in my opinion.
(In reply to comment #5) > Mmmh, but is this still useful if we only do the workspace-grouping for > windows? Yes it makes it easier to find the windows I am actually looking for. Also this would reflect what we do in the overview. You have all apps visible in the dash and only the windows of the current workspace to choose from. The other option would be to just limit it to the current workspace, but last time we had this discussion the compromise was the current implementation. (In reply to comment #6) > Workspaces are very useful - for organizing windows visually and spatially. The > application switcher is unrelated to that in my opinion. How so? When you use a workspace to have a set of apps/windows for a particular task having the app switcher mix in unrelated windows isn't exactly useful.
*** Bug 674680 has been marked as a duplicate of this bug. ***
Comment on attachment 198510 [details] [review] alt-tab: Ignore workspaces in popups This is more a prove-of-concept hack than an actual proposal - if we go that route, we should do it properly
Created attachment 225005 [details] [review] altTab: Remove the workspace separator It doesn't match the dash, and the current behavior is inefficient. I wrote this for some people while down in Largo since I couldn't find your patch. It's a bit more complete than yours. As a "task-based grouping" person, I actually like it. It's very rare that you switch workspaces by accident now, and it doesn't break the bounce of doubling alt-tab, which is the biggest annoyance. I suggest you try it out, drago01.
Created attachment 237157 [details] [review] altTab: Ignore workspaces in popups Picking up the original patch: rebased to master and cleaned up.
Created attachment 237158 [details] [review] switcherPopup: Remove separator support Since the alt-tab switcher stopped using separators, the functionality is unused, remove it.
This won't affect the window switcher, right?
(In reply to comment #13) > This won't affect the window switcher, right? The window switcher either shows windows from a single workspace or all workspaces, but doesn't do any grouping, so no, the patches only affect the app switcher (unless you mean the alt-` popup, which I changed as well - not so sure about that one though, some designers feedback would be good here)
(In reply to comment #14) > The window switcher either shows windows from a single workspace or all > workspaces, but doesn't do any grouping Ah, I never tested it in the full mode, and thought it used separators.
Review of attachment 237157 [details] [review]: This looks good, pending on designer ACK removal of separator in the thumbnails list.
Review of attachment 237158 [details] [review]: Same.
Sounds great to me. This was the original intention. Switching apps. With a very simple mental model of order - in order of use. Windows have locations. Apps don't. The window task grouping is done primarily in the window picker. +1
Ping on this?
Comment on attachment 237157 [details] [review] altTab: Ignore workspaces in popups I've found some edge cases where it doesn't behave like I think it should; I'm planning on work on this tomorrow before doing releases
Attachment 237157 [details] pushed as b50702d - altTab: Ignore workspaces in popups Attachment 237158 [details] pushed as f9d9caf - switcherPopup: Remove separator support Sorry for the noise - I was sure that dropping the use of META_TAB_LIST_NORMAL_ALL would reintroduce bug 667552, but apparently not. In general the behavior is much more predictable than the previous one, so I'm pushing it now - if we find corner cases that still behave unexpectedly, we can address those later.
*** Bug 634173 has been marked as a duplicate of this bug. ***
I don’t get it. There is switch-windows and switch-applications and they now work the same. What do I use to switch inside the current workspace? Is there really no way anymore? That would be so annoying.
(In reply to comment #23) > I don’t get it. There is switch-windows and switch-applications and they now > work the same. > > What do I use to switch inside the current workspace? Is there really no way > anymore? That would be so annoying. If you want to switch windows inside the current application: $ gsettings set org.gnome.shell.window-switcher current-workspace-only true
SSSI(In reply to comment #23) > I don’t get it. There is switch-windows and switch-applications and they now > work the same. No, they don't. switch-applications groups windows by applications, switch-windows doesn't. Also the latter has an option to only consider windows of the current workspace.
Nevermind. I just don’t care enough anymore. The terminal transparency issue broke my will to get involved.
$ gsettings set org.gnome.shell.window-switcher current-workspace-only true is not working for me. The at-tab always switch to last window in any workspace.
(In reply to comment #27) > $ gsettings set org.gnome.shell.window-switcher current-workspace-only true is > not working for me. > > The at-tab always switch to last window in any workspace. By default, alt-tab is used for the application switcher ("Switch applications" in the keyboard shortcut settings). Did you change both the switch-applications (to not use <Alt>Tab) and switch-windows (to use <Alt>Tab) shortcuts? The setting in question only applies to the window-based switcher, which does not have a default shortcut. (Also: comments on old and closed bugs get overlooked easily, better file new bugs - in particular as your issue has absolutely nothing to do with this bug)
Ok. Thanks a lot.