GNOME Bugzilla – Bug 786257
Alt-Shift-Tab switches keyboard layouts
Last modified: 2017-08-14 20:05:31 UTC
I just switched from Compiz to running Gnome 3.14 on Ubuntu 16.04LTS. I have installed and activated the Alternate Tab extension. Two keyboard layouts are configured. The keyboard shortcut to switch between keyboard layouts by default is Alt-Shift which makes sense, being the same also on other platforms (notably Windows) and across different Linux configurations.
However, each time I cycle through my windows backwards using the default keyboard shortcut Alt-Shift-Tab, the keyboard layout changes. I consider this a bug for the following reason:
The keyboard layout shall change if and only if I press and *release* the keyboard shortcut Alt-Shift. Therefore, if I press an additional key while holding Alt-Shift this must not trigger the events linked to the "Alt-Shift" shortcut, such as the keyboard layout change.
It seems that https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/36812 describes the same issue and that based on the refusal of the xkb team this issue still exists. Correct?
I now switched to Alt-CapsLock for keyboard layout switching. Interestingly and inconsistently, pressing Alt-CapsLock doesn't toggle CapsLock... ;-)
Thanks for taking the time to report this.
However, you are using version 3.14 that is too old and not supported anymore by GNOME developers. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes by GNOME developers for the version that you use.
By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME.
Please feel free to reopen this bug report if the problem still occurs with a recent version of GNOME (3.24 or 3.22), or feel free to report this bug in the bug tracking system of your Linux distribution if your distribution still supports the version that you are using.
Thanks for replying. Just to get things right: I'm on the latest Ubuntu LTS release, all updates installed, the Gnome version that ships seems this:
1:3.14+3ubuntu1 (/var/lib/apt/lists/de.archive.ubuntu.com_ubuntu_dists_xenial_universe_binary-amd64_Packages) (/var/lib/dpkg/status)
Description Language: en
1:3.14+3ubuntu1 - gnome-core (5 1:3.14+3ubuntu1) desktop-base (0 (null)) network-manager-gnome (2 0.9.10) bijiben (2 3.14) brasero (2 3.11) cheese (2 3.14) evolution (2 3.12) evolution-plugins (2 3.12) file-roller (2 3.14) gedit (2 3.14) gnome-clocks (2 3.14) gnome-color-manager (2 3.14) gnome-documents (2 3.14) gnome-games (2 1:3.14) gnome-getting-started-docs (2 3.14) gnome-logs (2 3.14) gnome-maps (2 3.14) gnome-music (2 3.14) gnome-nettool (2 3.8) gnome-photos (2 3.14) gnome-sound-recorder (0 (null)) gnome-tweak-tool (2 3.14) nautilus-sendto (2 3.8) gnome-orca (2 3.14) polari (0 (null)) rygel-playbin (2 0.24) rygel-tracker (2 0.24) seahorse (2 3.14) vinagre (2 3.14) alacarte (2 3.11) avahi-daemon (0 (null)) gimp (2 2.8) hamster-applet (2 2.91.3) inkscape (2 0.48) libreoffice-gnome (0 (null)) libreoffice-writer (0 (null)) libreoffice-calc (0 (null)) libreoffice-impress (0 (null)) rhythmbox (2 3.0) simple-scan (0 (null)) goobox (16 (null)) sound-juicer (0 (null)) transmission-gtk (0 (null)) xdg-user-dirs-gtk (0 (null)) cups-pk-helper (2 0.2) gedit-plugins (2 3.14) gnome-shell-extension-weather (0 (null)) gstreamer1.0-libav (2 0.10.13) gstreamer1.0-plugins-ugly (2 0.10.19) rhythmbox-plugins (0 (null)) rhythmbox-plugin-cdrecorder (0 (null)) telepathy-gabble (0 (null)) telepathy-rakia (0 (null)) telepathy-salut (0 (null)) totem-plugins (0 (null)) libgtk2-perl (2 1:1.130) gnome-software (0 (null)) xul-ext-adblock-plus (0 (null)) xul-ext-gnome-keyring (0 (null)) iceweasel-l10n-all (0 (null)) gnome:i386 (32 (null))
and you say that this is "too old and not supported anymore?" This really comes as a surprise, but I understand that you're now recommending to report this to some Ubuntu support forum.
Oh, and the output of the command
$ dpkg -l gnome-shell
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
ii gnome-shell 3.18.5-0ubuntu0.3 amd64 graphical shell for the GNOME desktop
So it seems that the output produced by "apt-cache showpkg" was misleading, and I'm actually on 3.18.5-0ubuntu0.3. Still too old to be taken care of or even try to reproduce in your environment without having me to risk a broken system and some dubious upgrade to a later Gnome version?
> and you say that this is "too old and not supported anymore?"
Correct. GNOME 3.14 was released in Sep 2014. Latest stable GNOME is 3.24.
Any distribution (especially "LTS" or "Enterprise" releases) is free to ship (and maintain) what they want. And any user is free to use conservative distribution (release)s which include ancient versions of GNOME, or free to switch to other distribution (release)s which ship more recent versions of GNOME.
FYI, Ubuntu has its issue tracker at https://bugs.launchpad.net/ubuntu/
GNOME developers basically care about GNOME 3.24 (latest stable) and some still care a bit about GNOME 3.22 until GNOME 3.26 will be released next month.
Upstream can only support the last released stable version, which is 3.24. If a distributor ships a version older than that, then this should be the first point of contact.
That said, the issue is certainly still present, at least if you are using X11 - it's simply that the X server handles <alt><shift> and the compositor (gnome-shell) doesn't even receive the key-press event for the shift key. We cannot fix the handling of an event we don't see in the first place, so this is not a GNOME issue. I doubt there's really an issue on the Xorg side either - after all, it handles <alt><shift> exactly the way it was configured to do. So the only advise I can give is to not set up conflicting keyboard options (there's a reason why the default for switching layouts is <super>space, and not <alt><shift> ...)
Thanks for the explanations. So it's an Xorg issue with how keyboard shortcuts are defined. Other operating systems, most notably Microsoft Windows, is capable of triggering a shortcut event only after that combination of keys is also *released* again with no additional key pressed (as has been described on some of the comments of the document I referred to in comment #1). To me the way Xorg and with it everything based on it handles shortcuts is simply inadequate and unnecessarily simplistic. As a user I cannot see a good reason why it would be necessary to trigger the shortcut already upon press of the last key constituting the shortcut, not upon release.
I'll try reporting this for Xorg if I find out where and how. The sheer amount of comments on that other discussion which seems to argue in similar ways I do supports me in this.
Just for reference: https://bugs.freedesktop.org/show_bug.cgi?id=865 is the xorg issue for this.