GNOME Bugzilla – Bug 787627
Proposing a more advanced mode for alt-tab
Last modified: 2021-07-05 14:41:06 UTC
Alt-tab is generally showing up the switcher and give people the ability to switch between applications, raising all windows of an application if you don't enter into the window thumbnail subview to select a particular window. Alt + key above tab enables switching between the last 2 windows of the current focused applications. A case that happens to more advanced user is to switch between 2 windows of the last 2 applications. You can see a documentation browser in the background for instance and a terminal overlapping it. (the terminal has more than one window on this workspace). The issue is that you are fine with the terminal on top of the browser. However, if you alt-tab to the browser and alt-tab back (even without the switcher displayed), you will end up with all windows from your terminal raising, and so, covering your browser. This is clearly for advanced users, and that's why I think we can achieve a smarter/more advanced alt-tab behavior without breaking the paradigm: In case of a quick alt-tab (before the switcher UI shows up), we can cover the power user use-case, which is to switch quickly between the last focused window of the last 2 applications. To sum that up in a simple case: - you have an application with one instance, maximized - you have another application with multiple instances, like multiple terminals, not maximized. If you press alt-tab, even quickly, the whole second application would be raised (as no window has been selected). The consequence is that you have all terminal in front of, for instance, your browser or documentation viewer you are using. The behavior we implement enables this. However, as soon as the switcher ui is displayed to the user, not selecting a particular window instance will raise the whole applications. Consequently only "quick alt-tab" flow is impacted. Here is a video of the current upstream behavior: https://youtu.be/D32VEP0sFk4 Here is a video of the proposal: https://youtu.be/k-IBk-Fibj4 Tell me what do you think :)
Created attachment 359722 [details] [review] Proposed patch for quick alt-tab behavior
Changing alt+tab behavior from "switch to another application" to "switch to another application when done slowly, and to another window when done fast enough" sounds rather confusing. I'm tentatively -1 on this, but marking for ui-review in case the design team disagrees. Also I'm very much against making the switcher more sluggish by bumping up the timeout until the popup is shown.
Agree with Florian. Making things less predictable is not good IMO. This kind of issue almost always comes up with terminal applications and I believe that's where it should be fixed. gnome-terminal, for instance, could have an option (or a shortcut, whatever) where it opens up new windows under a dynamically created app ID so that they show up as separate toplevel apps. This would be useful for instance to group development terminals by project for instance.
This isn't an issue for just the Terminal but for any multiple document (MDI) app. I sometimes have multiple PDFs open in Evince and it's annoying to have all of them cover my workspace. Or browser windows, etc. I am looking forward to quarter tiling (maybe in 3.28) which can help a bit with my usecase. But I at least would appreciate if Alt-Tab did not raise all windows of an app when switching to one window. I guess GIMP is the most prominent example of an app where you probably do want multiple windows to show up but that can be worked around by using a separate workspace for GIMP or by using GIMP's single window mode.
I strongly support this proposal. This is one of the small changes, that a user doesn't recognize and still make the experience so much better. I remember many of those small things which increase productivity while testing Unity. I never thought about the inconsistency of the behaviour, I just used it and thought "somehow alt-tabbing works a lot better than with Gnome". Actually I ended up running Ubuntu live-systems from time to time because working with it just felt more productive. Good UX is not always about consistent behaviour, sometimes inconsistencies are so straightforward that you won't even notice them, and those are the ones which should be implemented. We shouldn't spend so much time thinking about how a feature doesn't make sense in theory if it does make sense in practice.
I agree too that the problem really exists and should be fixed, but I don't think this is the right way to fix it. Having two different results for the same action based on timing is bad for discoverability. In some case it is acceptable (think long press in touch interfaces to emulate right click), but multiplying the exceptions to the rule is bad for habits. Is there any options other than: - using an existing keybinding, and playing on the timing - using Yet Another Keybinding - changing the default behavior of Alt+Tab - adding an option to select the default behavior the user wants ? I agree none of these options look great, so maybe someone has a better idea?
> - using Yet Another Keybinding Just for reference, there is [Alt]+[Esc], which changes windows directly within an workspace, ignoring applications.
Also -1 from me. I would even want the Alt+Tab drawer to appear faster/instantly. As mentioned by António: Alt+Esc is the solution for the "Terminals over Firefox" problem, I guess most people simply don't know that this short-cut exists.
(In reply to António Fernandes from comment #7) > > - using Yet Another Keybinding > > Just for reference, there is [Alt]+[Esc], which changes windows directly > within an workspace, ignoring applications. Didn't know that one. That seems to do what Didier wants, even though the implementation is a bit weird as it doesn't trigger the overlaid window selector.
What do you think of the following behaviour where all windows which need to be put in the background get flagged by the Shell and those flagged windows will be preferably raised upon Alt+Tab: Terminal 1 Firefox 1 Terminal 2 Terminal 3 *Alt+Tab to Firefox* Firefox 1 Terminal 1 (flag) Terminal 2 Terminal 3 *Alt+Tab to Terminal* Terminal 1 Firefox 1 Terminal 2 Terminal 3 The difference becomes clear when there are more Windows in front of the Firefox window: Terminal 1 Terminal 2 Firefox 1 Terminal 3 *Alt+Tab to Firefox* Firefox 1 Terminal 1 (flag) Terminal 2 (flag) Terminal 3 *Alt+Tab to Terminal* Terminal 1 Terminal 2 Firefox 1 Terminal 3 Let's say there's also Evince involved: Terminal 1 Evince 1 Evince 2 Terminal 2 Firefox 1 Terminal 3 *Alt+Tab to Evince* Evince 1 Evince 2 Terminal 1 (flag) Terminal 2 Firefox 1 Terminal 3 *Alt+Tab to Firefox* Firefox 1 Evince 1 (flag) Evince 2 (flag) Terminal 1 (flag) Terminal 2 (flag) Terminal 3 *Alt+Tab to Terminal* Terminal 1 Terminal 2 Firefox 1 Evince 1 (flag) Evince 2 (flag) Terminal 3 *etc.* That way someone could easily switch between a tutorial in Firefox and *two* open terminals.
That's funny because that's *exactly* what I thought yesterday during my daily run :) I agree this model is superior and I guess will match the expectations of most people on quick alt-tab to come back to the exact same state as they were before. Then, once the switcher is shown, all windows are raised as you are raising the entire application. I'm happy to work on that solution if that fits design and the Shell team.
I agree, except that I still think that > Then, once the switcher is shown, all windows are raised as you are raising the entire application. would be confusing. The behaviour shouldn't depend on how fast you are ;) If someone really wants to bring up all windows of an application he can still use Alt+[key above Tab] or click on the app in the Dash.
Comment on attachment 359722 [details] [review] Proposed patch for quick alt-tab behavior We don't want different switcher behavior based on timing, so rejecting the patch to get it off the review list.
Florian, what do yo think about the flag list that Jan Niklas proposed? It sounds like an interesting idea to pursue, probably with design.
The first thing I do, and I suspect I'm not alone, is to immediately reconfigure Alt+Tab to perform tabbing between windows, and set Super+Tab to do its previous role of tabbing between applications (groups of windows). I've never felt that anything else was needed, and certainly not 'intelligent' (presumptuous!) behaviour for a single shortcut.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.