After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 606867 - Alt-tab behaviour is broken with multiple windows of same application
Alt-tab behaviour is broken with multiple windows of same application
Status: RESOLVED NOTABUG
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2010-01-13 15:53 UTC by Ole Laursen
Modified: 2011-04-19 11:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ole Laursen 2010-01-13 15:53:06 UTC
Hey!

I've been trying the shell from time to time, it's definitely interesting. One thing that keeps me off it is broken Alt-tab behaviour, though. To see the problem, open one window (X) of one application, then two windows (Y, Z) of another application (e.g. Epiphany). Then try Alt-tabbing between them. Don't hit any other keys than Alt and Tab. You'll soon end in a situation where you can only switch between X and Y (or X and Z) but not Y and Z. I think the weird grouping thing is the culprit.

Some context: I'm a heavy alt-tab user. The new-fangled Alt-tab popup thing looks nice, but I tend to think it's completely unnecessary because in my world Alt-tab is about fast switching with the keyboard right now. It's far too time consuming to start looking at the (changing) positions of the window icons and select the right with the mouse of arrow keys. The feature of being able to switch to apps in another work space is actually a bug in my world, because I sometimes overshoot the window and then would like start the cycle anew on the same desktop rather than being teleported to somewhere else. I think you should pull constrain the Alt-tab tab tab cycle to the same desktop, it might make sense to still show other apps so you can click on them but please don't let it mess with the cycle itself.
Comment 1 Emmanuel Pacaud 2010-04-20 17:49:52 UTC
As a workaround, you may want to use ALT+Esc, which switches between all windows of the current workspace.

I agree with you the ALT-Tab behavious is broken. It's possible to select one of the grouped windows using the arrow keys, but that's not very convenient.

Another thing that bugs me is the fact the layout of the window switcher is not the same as the layout of the workspace overview. It doesn't help to remember where things are.
Comment 2 Rui Matos 2011-04-16 00:52:35 UTC
Is Alt+Above_Tab enough for you to consider this bug fixed?
Comment 3 Ole Laursen 2011-04-17 15:35:59 UTC
No, sorry.

Even if you consider broken keyboard navigation a feature, why would you put it on Alt-Tab which has been a standard since at least Windows 3.11 (I don't know about Unix, but I'm pretty sure it was a standard here too when I switched to Linux ten years ago)?
Comment 4 Rui Matos 2011-04-17 17:01:45 UTC
Well, the current behavior is as designed and allows you to reach every possible window:

Alt+Tab - cycle through running applications
Alt+Above_Tab - cycle through windows of a given application (either the current one or one selected first with Alt+Tab)

There's currently an Alt+Tab special case of "switch to the most-recently-used window even if it's in the same app" but that should be going away soon as it's more confusing than helpful in practice, see bug 647907.

If you have specific enhancements/changes in mind, please post them, otherwise we can't keep this bug open as what's being requested is too vague (i.e. please state explicitly what you consider "broken").
Comment 5 Ole Laursen 2011-04-18 13:18:04 UTC
Well, you asked me, and I gave you my honest opinion. Note that this was never about reachability in itself, it was about convenient reachability.

I think it's a bad design choice because

- having two keybindings increases finger movements and cognitive load, slowing me down
- the current alt-tab is non-standard and thus really confusing, for a heavy alt-tab user it's like changing the copy-paste shortcuts (A Big Deal)

And it doesn't help that this is power-user stuff and completely non-discoverable.

What exactly is the tangible benefit of application grouping? I spent some time with Google now you started commenting, but all I found was annoyed people (including GNOME Shell devs) and no answers?

Note that bug 608946 is related.

If this is the wrong forum, please excuse me. When I filed this bug over a year ago, I thought it was just an early stage bug. I'm not sure where else to discuss this though.
Comment 6 Ole Laursen 2011-04-18 13:26:54 UTC
I should perhaps add that the use case I think is broken is really fast switching. The ones where you just hit Alt-tab once or twice and let go immediately without losing focus on the task.

This kind of switching starts to break down with standard Alt-tab if you have more than three windows in your working set, but in practice I find that most of my work happens in two windows where it works really.
Comment 7 Rui Matos 2011-04-18 18:05:12 UTC
(In reply to comment #6)
> I should perhaps add that the use case I think is broken is really fast
> switching. The ones where you just hit Alt-tab once or twice and let go
> immediately without losing focus on the task.

But that still works just as in gnome 2 if you don't have applications with more than 1 window. If you do, then you need Alt+Above_Tab too which is quite comfortably accessible since it's just above Tab.

I am a heavy Alt+Tab user myself (with lots of terminals etc.) and I got used to it pretty quickly after actually making an effort to change my mental model a bit. Now, when I use gnome 2, I actually miss the way gnome-shell works. So, really, it's just a matter of habit.
Comment 8 Ole Laursen 2011-04-18 19:27:17 UTC
Well, good for you. But I fail to see how that answers my questions?

Why do you miss the way gnome-shell works when you're in Gnome 2? Because you like being able to switch between your many terminals exclusively?
Comment 9 Ole Laursen 2011-04-18 20:15:00 UTC
I found what I guess is the original design notes here on page 22:

http://www.gnome.org/~mccann/shell/design/GNOME_Shell-20090705.pdf

Couldn't find any rationale. :( At that point it seems Alt-½ wasn't invented. The mentioned fast mouse navigation doesn't work for me as my job mostly involves typing, not mouse work.

The consequences of this design choice seems to me to run counter to two of the principles mentioned in the beginning of that document, "Principle of Least Astonishment" and "Less is more - Reduce Visual, Memory, Intellectual, and Motor work (and complexity)". But of course those two are so general that you could probably claim the contrary.
Comment 10 Dan Winship 2011-04-18 20:21:07 UTC
Design-wise, GNOME Shell's Alt+Tab is more of a replacement for GNOME 2.x's window list than it is for GNOME 2.x's Alt+Tab.

There is an extension in gnome-shell-extensions that makes Alt+Tab act like 2.x's again.

Closing this as NOTABUG, since the current behavior is per design, and bugzilla is not a useful place to argue about design decisions (as evidenced by the fact that this bug sat unanswered for more than a year).
Comment 11 blix 2011-04-18 20:37:45 UTC
Closing it "as-designed" is highly disingenuous.  The bug is obviously stating that the design is wrong, so as-designed is not helpful.

You have also failed to counter the previous points made.  Changing alt tab is confusing and inconvenient.  It buys you nothing at the expense of expected behavior.  The new behavior is neither simpler nor more useful.

A more reasonable solution would be to make alt-tab the same as it was in GNOME 2 and assign new behavior to alt-above-tab that satisfies whatever behavior you want.  That way you don't break people's behavioral habit.

I really see no justification in closing this.
Comment 12 Dan Winship 2011-04-18 21:08:49 UTC
(In reply to comment #11)
> Closing it "as-designed" is highly disingenuous.  The bug is obviously stating
> that the design is wrong, so as-designed is not helpful.

And as I said, arguing about design in bugzilla is not useful. The designers don't read bugzilla, and so arguments here will have no effect on what they think. (As seen by the past year of inactivity on this bug.)

> You have also failed to counter the previous points made.

Correct.
Comment 13 Colin Walters 2011-04-18 21:14:38 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > Closing it "as-designed" is highly disingenuous.  The bug is obviously stating
> > that the design is wrong, so as-designed is not helpful.
> 
> And as I said, arguing about design in bugzilla is not useful. The designers
> don't read bugzilla, and so arguments here will have no effect on what they
> think. (As seen by the past year of inactivity on this bug.)

To put a different (more positive =)) spin on it: bugzilla is not a really great mechanism for discussing design changes, because often people come in and just report one little detail of their workflow or one idea they'd like to implement, and it's really hard to evaluate from that perspective.

Probably more useful for the designers is plain data, like:

"I found Alt-Tab confusing after switching from GNOME 2"

That kind of feedback is useful, and even if the design doesn't change, it at least helps us understand what to put in the documentation.  We should probably have an explicit "transitioning from GNOME 2" document at least.  The current user docs don't seem to have a section about this which we should probably add.
Comment 14 Ole Laursen 2011-04-19 08:47:03 UTC
Actually, I was thinking the same, although I must admit I was hoping to see a designer show up anyway. I'd rather have this closed than spending more time discussing with people who don't have the power to change the decision. :)

Eh, sorry about this extra spam, but how do you go about talking this over with the responsible designer, whom should I talk to?
Comment 15 Milan Bouchet-Valat 2011-04-19 11:08:38 UTC
Ask on the #gnome-shell IRC channel, where you should probably ping mccann.