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 650452 - Alt+Shift+Tab to go back in window list
Alt+Shift+Tab to go back in window list
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
3.0.x
Other Linux
: Normal enhancement
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2011-05-18 02:07 UTC by Michael Ekstrand
Modified: 2011-07-06 12:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
altTab: honor switch_*_backward key binding actions (1.28 KB, patch)
2011-07-05 22:11 UTC, Rui Matos
reviewed Details | Review
altTab: honor switch_*_backward key binding actions (3.49 KB, patch)
2011-07-05 22:30 UTC, Rui Matos
committed Details | Review

Description Michael Ekstrand 2011-05-18 02:07:46 UTC
In the Alt+Tab window switcher, I would like to be able to press Alt+Shift+Tab to go back.  This feature is offered by Compiz (and I believe Metacity).

If there is a way to configure this, I could not find it in the Gnome 3 keyboard shortcuts dialog on Fedora 15 Beta.
Comment 1 Jasper St. Pierre (not reading bugmail) 2011-05-18 02:54:43 UTC
This feature already exists, however you may have a faulty metacity configuration. Can you run:

$ gconftool-2 -u /apps/metacity/global_keybindings/cycle_windows_backward

and see if this fixes the problem?
Comment 2 Michael Ekstrand 2011-05-18 03:10:44 UTC
I did that, but I still cannot use Alt+Shift+Tab.
Comment 3 Jasper St. Pierre (not reading bugmail) 2011-05-18 03:23:15 UTC
Er, excuse me, sorry, the *correct* binding is switch_windows_backward:

$ gconftool-2 -u /apps/metacity/global_keybindings/switch_windows_backward
Comment 4 Michael Ekstrand 2011-05-18 03:30:22 UTC
That does make it work.

Is this a broken remnant from my previous Gnome 2 config, so this will generally work for new users (in which case I am fine with closing the bug), or is there something outstanding that should still be done to leave the bug open?
Comment 5 Rui Matos 2011-05-18 09:38:52 UTC
(In reply to comment #4)
> That does make it work.
> 
> Is this a broken remnant from my previous Gnome 2 config, so this will
> generally work for new users (in which case I am fine with closing the bug), or
> is there something outstanding that should still be done to leave the bug open?

Yes, it's what you once configured for metacity (which should also have worked, whatever it was).
Comment 6 Dan Winship 2011-05-18 11:12:57 UTC
it seems that it's broken by default on ubuntu, for people who have used compiz, because switch_windows_backward is set to "Alt+Shift+Tab", which you would think would work, but it doesn't. We should probably fix that.
Comment 7 Rui Matos 2011-05-18 11:25:12 UTC
(In reply to comment #6)
> it seems that it's broken by default on ubuntu, for people who have used
> compiz, because switch_windows_backward is set to "Alt+Shift+Tab", which you
> would think would work, but it doesn't. We should probably fix that.

Indeed, I just tried and it does bring up the Alt+Tab popup but doesn't work past that.

Although the original reporter here isn't using Ubuntu, the Ubuntu problem is probably the same yes. For the record, here's the Ubuntu change that sets switch_windows_backward:

https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/150702
Comment 8 Michael Ekstrand 2011-05-18 13:10:39 UTC
My Gnome Shell/Mutter install is on Fedora, but the old configuration was from Ubuntu.
Comment 9 Dinh 2011-06-14 07:50:56 UTC
Same issue - Alt+Tab Works; Alt+Shift+Tab Failed. Setting /apps/metacity/global_keybindings/switch_windows_backward to disabled solved it.

This is coming from a fairly fresh Xubuntu 11.04 Install which then replaced with Gnome-Shell and XFCE removed. Gnome-Shell was installed through the GNOME3 PPA.
Comment 10 Jean-François Fortin Tam 2011-07-05 19:50:20 UTC
I ran into this issue on Fedora (#711251), possibly because it was a machine that was previously running Ubuntu. In any case, here's an interesting bit of conversation:

<magcius> The bug is that we ignore the switch_windows_backward key, which IIRC was on purpose for some reason
<danw> well, the bug is more that we *don't* ignore it
<danw> it was always the case that if the key was unset, then it was assumed to be switch_windows+Shift. it apparently used to be the case that you could set it explicitly to Alt+Shift+Tab if you wanted (but not anything else), but at some point it got broken to not allow even that
<magcius> https://bugzilla.gnome.org/show_bug.cgi?id=639341#c15
Comment 11 Rui Matos 2011-07-05 22:11:12 UTC
Created attachment 191369 [details] [review]
altTab: honor switch_*_backward key binding actions
Comment 12 Jasper St. Pierre (not reading bugmail) 2011-07-05 22:18:21 UTC
Review of attachment 191369 [details] [review]:

You should also modify windowManager.js so that it works without an alt-tab popup open.

A better commit message could be better as well:

  We weren't honoring SWITCH_*_BACKWARD key bindings before, causing the
  unfortunate effect of making the switcher completely useless.
Comment 13 Rui Matos 2011-07-05 22:30:18 UTC
Created attachment 191370 [details] [review]
altTab: honor switch_*_backward key binding actions
Comment 14 Rui Matos 2011-07-05 22:32:12 UTC
This should fix it for good. From the discussion in bug 639341 I concluded, at the time, that these switch_*_backward key bindings were to be marked as deprecated and removed them. I didn't think of people upgrading nor that distributors (namely Ubuntu) were patching metacity to explicitly set those keys.

(In reply to comment #12)
> A better commit message could be better as well:
> 
>   We weren't honoring SWITCH_*_BACKWARD key bindings before, causing the
>   unfortunate effect of making the switcher completely useless.

Feel free to add one when committing.
Comment 15 Jasper St. Pierre (not reading bugmail) 2011-07-05 22:42:03 UTC
Review of attachment 191370 [details] [review]:

::: js/ui/altTab.js
@@ +163,3 @@
             }
+        } else if (binding == 'switch_group_backward') {
+            this._select(0, this._appIcons[0].cachedWindows.length - 1);

Hm. I'm not sure I like this.

Can we try something like:

    // Additionally match "*_backward" bindings.
    if (/_backward$/.test(binding)) {
        backward = true;
        binding = binding.slice(0, -'_backward'.length);
    }

@@ +231,3 @@
             this._select(this._currentApp, backwards ? this._previousWindow() : this._nextWindow());
+        } else if (action == Meta.KeyBindingAction.SWITCH_GROUP_BACKWARD) {
+            this._select(this._currentApp, this._previousWindow());

Similarly here, it might be nicer to just set the backward flag:

    if (action == Meta.KeyBindingAction.SWITCH_GROUP_BACKWARD ||
        action == Meta.KeyBindingAction.SWITCH_WINDOWS_BACKWARD)
        backward = true;
Comment 16 Rui Matos 2011-07-05 22:57:08 UTC
Review of attachment 191370 [details] [review]:

::: js/ui/altTab.js
@@ +163,3 @@
             }
+        } else if (binding == 'switch_group_backward') {
+            this._select(0, this._appIcons[0].cachedWindows.length - 1);

That just doesn't "read" as nicely IMO.

@@ +231,3 @@
             this._select(this._currentApp, backwards ? this._previousWindow() : this._nextWindow());
+        } else if (action == Meta.KeyBindingAction.SWITCH_GROUP_BACKWARD) {
+            this._select(this._currentApp, this._previousWindow());

The backward flag here is really just indicating that Shift is pressed, so no, I don't think this would be better. 

Actually to be really complete it should be like this:

        } else if (action == Meta.KeyBindingAction.SWITCH_GROUP_BACKWARD) {
            this._select(this._currentApp, backwards ? this._nextWindow() : this._previousWindow());

Which is how metacity itself deals with this _BACKWARD bindings and Shift being an *additional* check on top of it. But this is just obfuscating the code without much real gain IMO. Who in their right mind is going to set SWITCH_GROUP_BACKWARD to, say <Alt>P and then expect <Alt><Shift>P to move the selector forward?
Comment 17 Rui Matos 2011-07-05 22:59:45 UTC
Big fail on my reply to you here Jasper :-) This is what I meant:

(In reply to comment #15)
> Hm. I'm not sure I like this.
> 
> Can we try something like:
> 
>     // Additionally match "*_backward" bindings.
>     if (/_backward$/.test(binding)) {
>         backward = true;
>         binding = binding.slice(0, -'_backward'.length);
>     }

That just doesn't "read" as nicely IMO.

The rest is understandable I guess.
Comment 18 Dan Winship 2011-07-06 12:46:57 UTC
Yeah, I'm happy with this version of the patch.

Rui, you should apply for a GNOME git account
(http://live.gnome.org/NewAccounts) so you can start committing your own
patches.

Attachment 191370 [details] pushed as 8db1ff8 - altTab: honor switch_*_backward key binding actions