GNOME Bugzilla – Bug 686613
Caps Lock can't be set as keyboard layout switch shortcut
Last modified: 2012-11-15 13:56:44 UTC
Many users prefer to use CapsLock to switch their keyboard layouts, and that worked in GNOME up to 3.4 (and Shift+CapsLock did original CapsLock function). But starting with 3.6, the setting has been moved, and it's no longer possible to set CapsLock as the layout switch shortcut. The only possible values for org.gnome.settings-daemon.peripherals.keyboard input-sources-switcher are combinations of alt, control and shift keys.
Not only that ... there is not possible to use common combinations such as just Ctrl+Shift, LShift+RShift or Shift+Capslock I was used to. That is pretty annoying.
May be the Configuration in Input Sources tab should allow that? But it is disabled all the time :/
(In reply to comment #0) > Many users prefer to use CapsLock to switch their keyboard layouts, and that > worked in GNOME up to 3.4 (and Shift+CapsLock did original CapsLock function). > But starting with 3.6, the setting has been moved, and it's no longer possible > to set CapsLock as the layout switch shortcut. AFAICT, it's not possible to do this currently from an X client without also triggering Caps Lock itself, that's why I didn't add combinations with CapsLock. A work around, if you don't need the CapsLock key functionality, is to set the ctrl:nocaps XKB option[1] and then choosing one the combinations that includes ctrl. To fix this properly we'd need to hook into the X server's internal key event handling. Wayland should allow us to that. [1] org.gnome.desktop.input-sources xkb-options (In reply to comment #1) > Not only that ... there is not possible to use common combinations such as just > Ctrl+Shift, LShift+RShift or Shift+Capslock I was used to. That is pretty > annoying. Those are not configurable in the official UI at the moment. You can still use some of them by setting the gsettings key org.gnome.settings-daemon.peripherals.keyboard input-sources-switcher . gnome-tweak-tool gives you a UI for that key.
> AFAICT, it's not possible to do this currently from an X client without also triggering Caps Lock itself, that's why I didn't add combinations with CapsLock. If so, how was it possible to do that in 3.4?
(In reply to comment #4) > > AFAICT, it's not possible to do this currently from an X client without also > triggering Caps Lock itself, that's why I didn't add combinations with > CapsLock. > > If so, how was it possible to do that in 3.4? It was the X server switching among XKB group indexes. We don't use that anymore in GNOME, see http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=b6e011ad16311e2985aa523cf9bceef74168f95e for the rationale.
Maybe you could add CapsLock to possible shortcuts and set ctrl:nocaps automatically when it's selected?
(In reply to comment #6) > Maybe you could add CapsLock to possible shortcuts and set ctrl:nocaps > automatically when it's selected? And then deal with confused users that can't enable CapsLock any more? No thank you. You better know what you're getting into if you want to use that key.
(In reply to comment #7) > (In reply to comment #6) > > Maybe you could add CapsLock to possible shortcuts and set ctrl:nocaps > > automatically when it's selected? > > And then deal with confused users that can't enable CapsLock any more? No thank > you. You better know what you're getting into if you want to use that key. Who need this anyway? Caps lock, in its original meaning, is useless now days. It should been set as layout switcher by default long time ago, like a specific gnome feature.
(In reply to comment #3) > A work around, if you don't need the CapsLock key functionality, is to set the > ctrl:nocaps XKB option[1] and then choosing one the combinations that includes > ctrl. > This workaround doesn't allow to use capslock as a single key to switch layouts. I confirm that this issue is a regression.
(In reply to comment #9) > This workaround doesn't allow to use capslock as a single key to switch > layouts. It does. Run these commands: $ gsettings set org.gnome.desktop.input-sources xkb-options "['ctrl:nocaps']" $ gsettings set org.gnome.settings-daemon.peripherals.keyboard input-sources-switcher ctrl-l
Yep, you are right, but it also affects Ctrl key behavior that's annoying.
(In reply to comment #11) > Yep, you are right, but it also affects Ctrl key behavior that's annoying. Yes, I confirm that. Is it possible to use Capslock for switching layouts without affecting Ctrl key?
Created attachment 227922 [details] [review] keyboard: Add combos with Caps Lock to the input sources switcher -- There's a window of time where the lock is in effect: between when the X server activates it on Caps Lock key press and we undo it on the first key release. Can't see how to get rid of that. Anyway, it works fine in practice. Please review.
(In reply to comment #13) > Created an attachment (id=227922) [details] [review] > keyboard: Add combos with Caps Lock to the input sources switcher > > -- > > There's a window of time where the lock is in effect: between when the > X server activates it on Caps Lock key press and we undo it on the > first key release. Can't see how to get rid of that. > > Anyway, it works fine in practice. Please review. Hi, thanks, I'm already using it. BTW, here is feature request: is it possible to switch layout when some other non-functional key (letter/digit/space/backspace) pressed? It's a very common case for me (and, I think, many others) when you press layout switching combo/key for a moment before releasing the key for the last typed symbol. Or for a moment before releasing backspace after deleting a text typed in a wrong layout.
Patch works fine (I've applied it to g-s-d 3.6.1), thanks.
*** Bug 687929 has been marked as a duplicate of this bug. ***
I am using the gnome 3.6.1 and can not set the CapsLock as a layout switcher! This is so far the most annoying bugs in gnome for me! :( Utilizing a useless key for switching layouts was so great!
Review of attachment 227922 [details] [review]: ::: plugins/keyboard/gsd-input-sources-switcher.c @@ +382,3 @@ + /* When the grab is established with Caps Lock as the modifier + (i.e. key.state == GDK_LOCK_MASK) we can't use + match_xi2_key() as this modifier is black listed there, so we I'd rather we found a way to fix this instead of working around it. It should be blacklisted when used as a modifier, not as a stand-alone key. @@ +469,3 @@ 1, &mods); + if (includes_caps && caps_press_time < switch_time) Is xev->time completely monotonic?
(In reply to comment #18) > Review of attachment 227922 [details] [review]: > > ::: plugins/keyboard/gsd-input-sources-switcher.c > @@ +382,3 @@ > + /* When the grab is established with Caps Lock as the modifier > + (i.e. key.state == GDK_LOCK_MASK) we can't use > + match_xi2_key() as this modifier is black listed there, so we > > I'd rather we found a way to fix this instead of working around it. > It should be blacklisted when used as a modifier, not as a stand-alone key. For the record: 10:40 < rtcm> hadess, right, let me explain a bit more what's going on there, we establish 2 grabs 10:41 < rtcm> one for shifted caps lock, and another one for caps locked shift, so that the shortcut works both ways (i.e. independently of which key you actually pressed first) 10:41 < rtcm> that workaround is for the caps locked shift case > @@ +469,3 @@ > 1, > &mods); > + if (includes_caps && caps_press_time < switch_time) > > Is xev->time completely monotonic? It's like all X timestamps so I'm almost sure it is monotonic although I can't actually find any specific mention to that in the x11 or XI2 protocol documents. Anyway, if it's not monotonic there's no way to properly do this. I.e. if the time goes back between the key press and the release what can we do? If it goes back at any other point it shouldn't matter since we always set caps_press_time on the key press that triggers the grab.
Ups, I forgot to use git bz. I pushed a revised version of this patch to both master and gnome-3-6: http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=bd1d5fbe09c76131276db6289f1f5f26ff5a3b6d
@Rui: thanks a lot! Will there be 3.6.3 release?
And I think it's expected behaviour, but I'll still leave it here: there is some timeout before the layout change is actually performed: if you press CapsLock and immediately start typing something, you may get first one or two letters typed in previous layout, like: йцertyui. This is a bit annoying :(
Just my 2 cents: this delay happens with another key combinations as well.
(In reply to comment #22) > And I think it's expected behaviour, but I'll still leave it here: there is > some timeout before the layout change is actually performed: if you press > CapsLock and immediately start typing something, you may get first one or two > letters typed in previous layout, like: йцertyui. This is a bit annoying :( I just pushed a patch which should make this better for shortcuts using Caps Lock. See bug 688350. (In reply to comment #23) > Just my 2 cents: this delay happens with another key combinations as well. For other keys we can't really shorten the delay without disturbing applications, see the above mentioned bug for a more detailed explanation.