GNOME Bugzilla – Bug 608946
alt+tab improvement
Last modified: 2013-02-12 05:16:15 UTC
i find gnome-shell's alt+tab to be very strange. it's actually pretty much the reason that i'm not using it. here's how i think it could be done better: first: for any reasonable solution, i think all behaviour dependent on which windows are parts of the same application should be removed. i guess that may be controversial, but it *really* annoys me. what i believe should happen is this: the list that comes up when you hit alt+tab should have your workspaces listed on the top row and inside of each workspace (ie: popping down under it) are the windows on that workspace, in order of how recently they were interacted with (with the exception that minimise sends a window to the end of the list). the current desktop should be preselected and you should find yourself cycling between the windows on that desktop. ie: basically exactly how metacity does it. the difference, of course, would be that you'd also be able to navigate left/right with the keyboard or mouse while still holding down alt. you'd also be able to press 'up' to go up to the workspaces list and select another workspace to move within.
I would add an idea here. Instead of focus in workspaces, we must focus on applications (I think this is the philosophy of the whole idea): when using alt-tab, it is quite annoying having to us both hands to select between multiple windows from the same applications. It would be possible to us the key just above Tab to navigate the windows opened in one application. That is: application X have 3 windows associated (x1, x2, x3). When selection X using Alt-tab, and holding Alt, ` (in us keybords, the equivalent in the rest of keyboards, i am using spanish one) would cycle between the different windows in application x1, x2, x3. Now, AFAIK, you must select X using alt-tab, hit down arrow and right-left arrow to select x1, x2, x3. And hitting again Tab would go back and continue cycling between applicatiosn. Easy and one-handed. I should recognised the problem came around to my mind some time ago, but the way out posted here is not my own. It seems to be suggested by Mairin in one of the comments in Usability Test Plan blog, but it is not working yet or it is not working for me... (http://mairin.wordpress.com/2010/02/10/gnome-shell-usability-test-plan/) Any comments??
that's bug 596231
I was under the impression that we are supposed to act as if users are primarily interested in documents -- not applications. This is why, for example, MDI is a really terrible idea. In many situations you're using the same application for two entirely unrelated tasks. The web browser is a great example here. Say I'm doing two tasks at the same time: - using the web browser to look at my bank accounts and fill data into a spreadsheet - using the web browser with gmail to write a letter to someone using notes from a text document Under the alt+tab-is-application-aware model, the computer starts to act like my writing an email and my looking at my bank account have something to do with each other. Of course they don't. Really, I want my computer to know that the bank account and the spreadsheet are related and that gmail and my text document with the notes are related. Unfortunately, we don't have any good way to guess what higher-level "tasks" the user might be doing unless they split them into separate workspaces. Any complicated heuristic that we could develop to guess would likely result in unpredicable behaviour. In this case, I really think the very best thing to do is to have alt tab follow the "most recently interacted" rule -- that's really the one that's most likely to give you the window you want under the assumption that you work on one task for a little while before context switching. One could argue that maybe we ought to special-case the web browser, but it's not the only "special" application here. I can easily be editing unrelated word processor documents or performing unrelated actions in several terminals or ....
Side note: if I'm looking at my spreadsheet and I switch back to my bank account and you bring the gmail window forward along with the bank account window I'm going to be *very* upset.
that's bug 609707 :-}
Current alt+tab is broken by design, let me show you. My current desktop #1: 3 terminal windows and 7 empathy chat windows open. Terminal 1 is active. I talk to a friend exchanging code snippets. To switch to terminal 2 I need to press either: * alt+tab, alt+shift+tab, alt+` (next app, previous app, next window) * or alt+tab, left, down, right (next app, previous app, window mode, next window) ...at the same time guessing which of the ~identical white blocks labeled "patrys@localhost:~" is the terminal I need :) Same thing whenever I want to switch to another chat window (same combinations, all windows similar, just better labelled). To make it worse, shell raises all three terminal windows and all 7 chat windows at the same time. It took quite some work to arrange windows in such a way that I able to see the terminal while typing in chat. Same thing happens when I open multiple GIMP windows working on a website - whenever I switch from the reference file to a GIMP window, all windows get raised and cover the entire screen. I believe users are more likely to think in terms of documents, not apps. My three terminal windows are unrelated. My 7 chat windows are unrelated. Chances are the 6 OpenOffice documents you happen to have opened at the same time are unrelated too. I propose making alt+tab behave like it used to: cycle windows by last use/urgency hint. At the same time introduce super+tab with the current behavior. Also please bring back the outline or otherwise mark the currently selected window.
Here is an example for people too lazy to try themselves ;) http://www.flickr.com/photos/patrys/4754552586/in/photostream/
Yeah, gnome-shell's Alt-Tab is more of a replacement for GNOME 2's Window List than it is a replacement for GNOME 2's Alt-Tab. (Note, for example, that it's much easier to navigate the Alt-Tab window using the mouse than it is using the keyboard.) Not saying that's a good thing, just that it's true.
Yeah, it's quite useful for mouse navigation (would be more useful if it displayed urgency hints), that's why I suggest keeping it as super+tab.
Reading through, the comment about all the terminal windows with [user]@[host] and the indistinguishable blocks of white. Maybe we could make a small improvement by having a close up of the top right corner (maybe top left in LTR locales?) of the window. That's usually where most of the activity or identifying characteristics are, and at the very least, showing a smaller section will have a greater chance of something being readable. If I could see the first few lines of console output, I could tell my terminals apart.
(In reply to comment #6) > I propose making alt+tab behave like it used to: cycle windows by last > use/urgency hint. At the same time introduce super+tab with the current > behavior. Also please bring back the outline or otherwise mark the currently > selected window. Agreed. Or you can use alt+` for the current behaviour (you can sill press up and down). Plus, if there's only one window with the current app, what's the point of alt+` cycling only through the current "app windows" (which is only one), after reaching the last one it should go to the next app.
Created attachment 190977 [details] [review] Make alt-tab and alt-above_tab cycle apps/windows from active workspace only I'll try this and see if I feel any better than with the current design.
OK after a day using gnome-shell with my patch, I admit the "cycle apps within active workspace only" approach does not work for me. I think, when I see apps in the app switcher, I expect Alt-tab to cycle through all of them regardless what workspace they belong to. Cycling too soon keeps surprising me. Alt-tab through workspaces does not work well either, though. I think the ability to quickly switch to windows from appswitcher is a mistake. It gets in the way of a more often used operation ("cycle windows within current workspace"). I haven't tried this out yet, but I think we can turn the dash into appswitcher, by showing it outside overview mode, then we can turn alt-tab back to windows cycling switcher.
Sorry for spamming ... the ability to quickly switch to windows from _other workspaces_ is a mistake...
Review of attachment 190977 [details] [review]: According to comments, no longer being proposed. Marking to get off review list.
It would be nice if there is a way to switch back to previous application while holding alt. Sometimes I realize that I missed a key above tab. In this case I'd like while holding alt to switch back by using alt-shift-tab. Unfortunately it does nothing when I press alt-shift-tab when alt-tab switching was initiated and I didn't release alt. So I have to release alt and repeat alt-tab once to return back. I'd say it wouldn't hurt to be able to change direction of alt-tab'ing while pressing shift in addition.
(In reply to comment #16) > It would be nice if there is a way to switch back to previous application while > holding alt. Sometimes I realize that I missed a key above tab. In this case > I'd like while holding alt to switch back by using alt-shift-tab. Unfortunately > it does nothing when I press alt-shift-tab when alt-tab switching was initiated > and I didn't release alt. So I have to release alt and repeat alt-tab once to > return back. I'd say it wouldn't hurt to be able to change direction of > alt-tab'ing while pressing shift in addition. This was a separate bug, and has been fixed in 3.1. There is a workaround, though: $ gconftool-2 -u /apps/metacity/global_keybindings/switch_windows_backward
we have Alt-Tab for 'classic' alt-tab now, and Super-Tab for app-based alt-tab