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 681685 - Allow setting shortcut based only on a combination of two modifier keys, eg. Alt+Shift
Allow setting shortcut based only on a combination of two modifier keys, eg. ...
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: keyboard
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
: 682349 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-08-12 13:34 UTC by Elad Alfassa
Modified: 2013-10-19 18:08 UTC
See Also:
GNOME target: 3.6
GNOME version: ---


Attachments
keyboard: Add modifiers-only shortcuts to switch input sources (12.99 KB, patch)
2012-09-20 19:52 UTC, Rui Matos
none Details | Review
keyboard: Add modifiers-only shortcuts to switch input sources (12.42 KB, patch)
2012-09-21 02:40 UTC, Rui Matos
none Details | Review
keygrab: Do a synchronous grab on the master device (1.01 KB, patch)
2012-09-21 02:40 UTC, Rui Matos
none Details | Review
keygrab: Remove Shift from modifiers if it's the key we want to match (1.14 KB, patch)
2012-09-21 02:41 UTC, Rui Matos
none Details | Review
keygrab: Do a synchronous grab on the master device (1.01 KB, patch)
2012-09-22 20:28 UTC, Rui Matos
needs-work Details | Review
keyboard: Add modifiers-only shortcuts to switch input sources (14.64 KB, patch)
2012-09-22 20:39 UTC, Rui Matos
reviewed Details | Review
keygrab: Allow unmodified grabs if explicitly requested (4.83 KB, patch)
2012-09-22 20:40 UTC, Rui Matos
reviewed Details | Review
keyboard: Add single modifier shortcuts to the input sources switcher (2.98 KB, patch)
2012-09-22 20:41 UTC, Rui Matos
reviewed Details | Review
keygrab: Allow unmodified and synchronous grabs if requested (6.91 KB, patch)
2012-09-23 02:06 UTC, Rui Matos
committed Details | Review
keyboard: Add modifiers-only shortcuts to switch input sources (16.15 KB, patch)
2012-09-23 02:07 UTC, Rui Matos
committed Details | Review

Description Elad Alfassa 2012-08-12 13:34:35 UTC
This was not a problem a while ago, when GNOME allowed X to handle keyboard layout switching, but it is an issue now, because the most popular shortcut to switch keyboard layouts, alt+shift, can't be configured now since GNOME moved keyboard layout switching shortcut to be handled by the keyboard shortcut control panel.

This bug will effect a lot of users who are used to this shortcut to switch keyboard layout. Another popular switching combination is shift+capslock which also doesn't work since 3.5.x
Comment 1 Elad Alfassa 2012-08-12 13:39:51 UTC
note that without this kind of a keyboard shortcut, I can't seem to find any two-key combination which will be an easy replacement, thus making layout switching (which I need a lot) to be a cumbersome task.
Comment 2 Shlomi Israely 2012-08-12 13:58:32 UTC
I agree with Elad. this would be a big drawback of the desktop's usability for multilang users.
Comment 3 André Klapper 2012-08-13 13:35:11 UTC
Also see discussion in bug 666393; and especially bug 669742 comment 2.
Probably a duplicate.
Comment 4 Bastien Nocera 2012-08-18 18:34:55 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 682069 ***
Comment 5 Elad Alfassa 2012-09-12 12:52:48 UTC
This is not a duplicate of bug 68069.

Bug #68069 is about adding options such as compose key to the keyboard setting window, and that is indeed fixed. however, this bug is about something completely different: allowing keyboard shortcuts such as alt+shift, shift+capslock and so forth to switch between keyboard layouts.

There is no way to do so in GNOME3. Even super+space which was proposed by developers in #fedora-desktop is not working (and it's very uncomfortable). If this bug is not fixed before the 3.6 release, multilingual users will have no easy solution to switch between languages in gnome, thus making 3.6 very painful for them.
Comment 6 Elad Alfassa 2012-09-12 13:33:15 UTC
And yes, I am aware that until https://bugs.freedesktop.org/show_bug.cgi?id=865 is fixed, there won't be a way to fix this issue cleanly. But you must remember that perfect is the enemy of the good. Most GNOME users type in more than one language. 

Even if you can't read English, you still need English for usernames and passwords everywhere, so you'd end up having two layouts: English and your own language (be it Chinese, Japanese, Arabic, Hebrew, or anything else that does not use the Latin alphabet, and there are many of these).  

Switching keyboard layouts is something multilingual users do a lot. sometimes even in the same sentence. Having to take the hands off the keyboard, grab the mouse, then clicking on two tiny click targets is slow, inefficient, and hard. 

Not fixing this bug in time will clearly hurt every user who uses languages other than English in their daily computer use.

I think, personally, that this bug should be prioritized, otherwise the whole "Input Sources" feature will become counterproductive.

Of course, I do not want to be one of those people who starts flamewars, otherwise I'd publish a link to this bug in mailing lists and social networks. I don't want to do that because I value your time as a developer of GNOME, which is by whole an awesome, very well built and designed project.

This long comment was only written to expand on why I think this bug is critical, I hope nobody is offended or angered by it.

I would be happy to get a detailed answer (or better, a fix) to this. Thank you for reading this comment.
Comment 7 Bastien Nocera 2012-09-12 13:43:23 UTC
*** Bug 682349 has been marked as a duplicate of this bug. ***
Comment 8 Rui Matos 2012-09-12 13:59:14 UTC
(In reply to comment #6)

Just so that you don't feel ignored, I'm aware of this and will try to fix it for 3.6.
Comment 9 Alexandre Rostovtsev 2012-09-15 08:24:46 UTC
This should be a blocker for 3.6.
Comment 10 nikita.vetoshkin 2012-09-16 21:23:41 UTC
Sorry for meaningless comment, but that's a horrible drawback. Please fix this.
P.S. Maybe it's time to change status at least?
Comment 11 artkun 2012-09-18 16:57:34 UTC
This should be considered as a blocker bug. I really liked this dialog.
Comment 12 Bastien Nocera 2012-09-18 21:27:50 UTC
If you want to CC: yourself on the changes, you don't need to add any comments. Especially if they are as pointless and aggravating as the ones above.

(Changing the status to please people who don't know we barely ever use them.)
Comment 13 Arschlöch 2012-09-19 02:38:18 UTC
> pointless and aggravating as the ones above

If reports on regressions (i.e., removing features that people have been using for years, without providing adequate replacement) are "pointless and aggravating" for you, then I pity you.

> to please people who don't know we barely ever use them

How the heck do we know you don't use them? If you don't use 'em, remove 'em, huh?
Comment 14 André Klapper 2012-09-19 07:12:45 UTC
o63582: You missed the point. The initial comment is useful. Recent "me too!" comments that don't provide any info except for personal wishes are useless.
Comment 15 nikita.vetoshkin 2012-09-19 08:53:01 UTC
(In reply to comment #14)
> o63582: You missed the point. The initial comment is useful. Recent "me too!"
> comments that don't provide any info except for personal wishes are useless.

Someone could have changed status from UNCONFIRMED, written that it's a regression, will be fixed in 3.6 and thanked for the report. That's it :)
Comment 16 Sergey V. Udaltsov 2012-09-19 09:42:34 UTC
Rui, Bastien, this is really highest-priority blocker for Russian users (at least - but I suspect other languages are affected)
Comment 17 Bastien Nocera 2012-09-19 09:55:41 UTC
(In reply to comment #16)
> Rui, Bastien, this is really highest-priority blocker for Russian users (at
> least - but I suspect other languages are affected)

How does adding a comment like that help at all? It's already a blocker. What else do you expect us to do? You're taking time that could be used to fix the problem.
Comment 18 Sergey V. Udaltsov 2012-09-19 10:00:57 UTC
The Importance of that bug is still "Normal"/"normal". That's what caused my previous comment.
Apologies for not looking into blocker list @ddl
Comment 19 Bastien Nocera 2012-09-19 10:22:29 UTC
(In reply to comment #18)
> The Importance of that bug is still "Normal"/"normal". That's what caused my
> previous comment.

You should know better than anyone that we don't use most of those fields on a day-to-day.

> Apologies for not looking into blocker list @ddl

"GNOME target:	3.6"
in the bug status itself. It's also listed at the top of:
https://bugzilla.gnome.org/browse.cgi?product=gnome-control-center
Comment 20 Sergey V. Udaltsov 2012-09-19 10:29:21 UTC
Thank you! The Russian community got agitated by that regression, now at least people can be relieved, their voice is heard.
Comment 21 Rui Matos 2012-09-20 19:52:03 UTC
Created attachment 224856 [details] [review]
keyboard: Add modifiers-only shortcuts to switch input sources

--

This adds the necessary plumbing in g-s-d. At this point we can't do
an official UI in g-c-c but it will be possible to set the shortcut in
gsettings and I'll try to do a patch for gnome-tweak-tool.
Comment 22 Elad Alfassa 2012-09-20 19:58:22 UTC
> This adds the necessary plumbing in g-s-d. 

Fantastic! Thanks for working on this!

> at this point we can't do an official UI in g-c-c

"this point" being the 3.6 release cycle? This means there will be no (official) UI for this until GNOME 3.8?

I wish it was possible to do without UI changes (ie. like you set any other keyboard shortcut) but I guess that's a problem with X and not with GNOME.
Comment 23 Bastien Nocera 2012-09-20 20:36:25 UTC
(In reply to comment #22)
> > at this point we can't do an official UI in g-c-c
> 
> "this point" being the 3.6 release cycle? This means there will be no
> (official) UI for this until GNOME 3.8?

Yep, only gnome-tweak-tool.

> I wish it was possible to do without UI changes (ie. like you set any other
> keyboard shortcut) but I guess that's a problem with X and not with GNOME.

The problem is that it's so hacky to do outside of the X server that we can only implement it separately from the other key handling, which means that the UI has to go through hoops as well. It won't be pretty...
Comment 24 Elad Alfassa 2012-09-20 20:39:10 UTC
Will it be less hacky to do so if/when https://bugs.freedesktop.org/show_bug.cgi?id=865 is fixed?
Comment 25 Rui Matos 2012-09-21 02:40:44 UTC
Created attachment 224887 [details] [review]
keyboard: Add modifiers-only shortcuts to switch input sources

This adds an out of process helper similar to gsd-locate-pointer to
allow for grabbing of certain pre-defined modifier-only shortcut
combos.
--

Ray pointed on IRC that we need to grab every on every combination of
ignored modifiers besides the ones we actually want so that the
sohrtcut works when CapsLock or NumLock or both are on, and that this
is exactly what the code in gsd-keygrab.c already does.

So, I modified this patch to call that code instead of doing the grab
explicitly here and that also implied switching to XI2 for the event
handling on the filter.

This uncovered 2 limitations in gsd-keygrab.c, but the following 2
patches fix them. The other only consumer of this API, the media-keys
plugin, seems to work just as well with these changes as far as I
tested.
Comment 26 Rui Matos 2012-09-21 02:40:57 UTC
Created attachment 224888 [details] [review]
keygrab: Do a synchronous grab on the master device

This allows us to replay events that might be interesting to other
applications.
Comment 27 Rui Matos 2012-09-21 02:41:10 UTC
Created attachment 224889 [details] [review]
keygrab: Remove Shift from modifiers if it's the key we want to match

This allows us to match and thus have shortcuts consisting of a
modified Shift.
Comment 28 Rui Matos 2012-09-21 02:45:14 UTC
(In reply to comment #24)
> Will it be less hacky to do so if/when
> https://bugs.freedesktop.org/show_bug.cgi?id=865 is fixed?

No, I'm not using that mechanism at all. I could if we did the key grabbing in gnome-shell though, so for 3.8 we'll probably revisit this and that patch might be helpful (not sure, didn't look at it).
Comment 29 Elad Alfassa 2012-09-21 12:37:19 UTC
Maybe when this patch is applied, you could change g-c-s to enable alt+shift layout switching automatically when you add a new keyboard layout?
Comment 30 Kamil Páral 2012-09-21 15:30:04 UTC
Hello, does this bug also concern the ability to switch layout using just CapsLock key, or does it concern just two-keys combinations (Alt+Shift and similar)?

From GNOME 2 to GNOME 3.4 I've been using CapsLock to switch the layout and the keyboard indicator marked currently active layout (off = English, on = Czech). I mention this because I am used to switch layouts several times in a single sentence, thus e.g. dozen times per minute. Single key press (CapsLock) is much better for me than multiple key press (Alt+Shift) and I would be very sad to see it go away.

Is there any way to use the old configuration dialog in GNOME 3.6 instead of the new one?

If this is not in the scope of this bug, tell me and I'll create a separate one.
Comment 31 Sergey V. Udaltsov 2012-09-21 15:40:32 UTC
Kamil, you can specify XKB options in gsettings. No GUI for that so far.

No you cannot use anything from 3.4 since Input Methods configuration was heavily redesigned.
Comment 32 Sergey V. Udaltsov 2012-09-21 15:41:26 UTC
Rui, BTW, if you are going to fix it for Caps, could you please add switching by RCtrl - that is what I am using.
Comment 33 Elad Alfassa 2012-09-21 15:57:59 UTC
(In reply to comment #30)
> Is there any way to use the old configuration dialog in GNOME 3.6 instead of
> the new one?
We should open a new bug (after these patches are reviewed and pushed) to get some sort of a UI for that into gnome-tweak-tool, should be simple enough to do, one combo-box with all the possible options.
Comment 34 Sergey V. Udaltsov 2012-09-21 16:00:18 UTC
One combo??? There are multiple GROUPS of options. Some of them allow multiple selection, some don't.
Comment 35 Elad Alfassa 2012-09-21 16:06:38 UTC
(In reply to comment #34)
> One combo??? There are multiple GROUPS of options. Some of them allow multiple
> selection, some don't.
Yes, one. I think you can fit all these states:
+  GSD_INPUT_SOURCES_SWITCHER_OFF,
+  GSD_INPUT_SOURCES_SWITCHER_ALT_SHIFT_L,
+  GSD_INPUT_SOURCES_SWITCHER_ALT_SHIFT_R,
+  GSD_INPUT_SOURCES_SWITCHER_CTRL_SHIFT_L,
+  GSD_INPUT_SOURCES_SWITCHER_CTRL_SHIFT_R

(from the patch) in one combo box
Comment 36 Sergey V. Udaltsov 2012-09-21 16:17:34 UTC
sorry I meant all xkb options that were available in 3.4
Comment 37 Kamil Páral 2012-09-21 16:18:47 UTC
(In reply to comment #31)
> Kamil, you can specify XKB options in gsettings. No GUI for that so far.

If the old gsetting values ("org.gnome.libgnomekbd.keyboard options") are still honored even in GNOME 3.6, I'm totally happy. It's an advanced stuff and I understand there might be no GUI for it, that's fine.
Comment 38 Matthias Clasen 2012-09-21 16:47:46 UTC
(In reply to comment #36)
> sorry I meant all xkb options that were available in 3.4

Even if it is a tweak tool, I don't think we should put _all_ options in there. The options that we've discussed for showing in the tweak tool are listed in bug 678171. That bug also contains a discussion about migrating org.gnome.libgnomekbd settings over.
Comment 39 Matthias Clasen 2012-09-22 00:29:47 UTC
I've tested this now, and I guess it works as well as can be expected
from this kind of approach.

What takes a little getting used to is that one has to release the
keys in the right order. E.g. with the setting 'alt-shift-l', I have
to generate the sequence press Alt - press Shift - release Shift -
release Alt. If I just hit the keys together quickly, I often end up
generating an order where I release Alt before Shift, in which case we
get a key release event for the Shift key without the Alt modifier,
thus not triggering the switch. Can we grab these combinations both
ways, ie look for an Alt release with the Shift modifier as well ? I
think that would make this much less frustrating.

It doesn't seem to work in the overview though. Wasn't that supposed
to be the advantage of this approach over ISO_Next_Source ?
Comment 40 nikita.vetoshkin 2012-09-22 10:30:15 UTC
(In reply to comment #39)
> It doesn't seem to work in the overview though.
It doesn't work if Synapse(launcher) window is active either.
Comment 41 Elad Alfassa 2012-09-22 11:12:18 UTC
Other combinations (unrealted to this patch) and media-keys don't work in the overview either, see bug #643111
Comment 42 Rui Matos 2012-09-22 20:28:04 UTC
Created attachment 224998 [details] [review]
keygrab: Do a synchronous grab on the master device

--
Just rebased.
Comment 43 Rui Matos 2012-09-22 20:39:47 UTC
Created attachment 224999 [details] [review]
keyboard: Add modifiers-only shortcuts to switch input sources

--
(In reply to comment #39)
> What takes a little getting used to is that one has to release the
> keys in the right order. E.g. with the setting 'alt-shift-l', I have
> to generate the sequence press Alt - press Shift - release Shift -
> release Alt. If I just hit the keys together quickly, I often end up
> generating an order where I release Alt before Shift, in which case we
> get a key release event for the Shift key without the Alt modifier,
> thus not triggering the switch. Can we grab these combinations both
> ways, ie look for an Alt release with the Shift modifier as well ? I
> think that would make this much less frustrating.

Yep, I've re-worked the patch to do that now. Seems much better
indeed.

I had to do adjustments to how we match the keys though because when a
modifier is released, the event state includes the modifier
itself. Doing this I realised that my previous patch to
match_xi2_key() is no longer needed and instead I can do all the
fudging before calling into it which should make this patch even safer
since the behavior of match_xi2_key() isn't changed at all now.

I also had to add some extra effort for the right Alt case since in
many keyboard layouts right Alt is actually the ISO_Level3_Shift key.

> It doesn't seem to work in the overview though. Wasn't that supposed
> to be the advantage of this approach over ISO_Next_Source ?

No, the advantage of not using ISO_Next_Source is that ISO_Next_Source
would be confusing if used in the overview because it would actually
change the XKB group (which we use undercover sometimes) but since we
wouldn't be able to catch it there, the input source wouldn't change.
Comment 44 Rui Matos 2012-09-22 20:40:55 UTC
Created attachment 225000 [details] [review]
keygrab: Allow unmodified grabs if explicitly requested

Unmodified grabs are sometimes useful. This adds the option for
calling code to be able to request a grab bypassing the whitelisting
of allowed unmodified keysyms.

--
This is only needed if we want to add single modifier shortcuts like
Right Alt alone. See next patch.
Comment 45 Rui Matos 2012-09-22 20:41:03 UTC
Created attachment 225001 [details] [review]
keyboard: Add single modifier shortcuts to the input sources switcher
Comment 46 Matthias Clasen 2012-09-22 21:26:00 UTC
Review of attachment 224998 [details] [review]:

I think this is a problem for the other uses of grab_key_unsafe in the media keys plugin. Try hitting one of the grabbed media keys, and observe that you will loose all keyboard input from then on.

How about changing the key grab api a bit more to

GsdKeyGrabFlags {
  GSD_KEY_GRAB_ALLOW_UNMODIFIED,
  GSD_KEY_GRAB_SYNCHRONOUS
}

grab_key_unsafe (Key *key, GsdKeyGrabFlags flags, GSList *screens)
ungrab_key_unsafe (Key *key, GSList *screens)

This addresses a number of other issues I have with the api and your changes to it:

- Calling the enum GsdKeygrabMode invites confusion with the X concept of GrabMode

- Much better to have separate functions for grab and ungrab, imo
Comment 47 Matthias Clasen 2012-09-22 21:29:39 UTC
Review of attachment 225000 [details] [review]:

See my earlier api comments
Comment 48 Matthias Clasen 2012-09-22 21:34:21 UTC
Review of attachment 224999 [details] [review]:

This looks fine to me
Comment 49 Matthias Clasen 2012-09-22 21:34:42 UTC
Review of attachment 225001 [details] [review]:

Looks fine to me
Comment 50 Matthias Clasen 2012-09-22 21:38:01 UTC
The behaviour is good now. Grabbing 'both ways' makes it much better. And the single-modifier options work fine too.

Now we just need to fix the sync grab issue.
Comment 51 Rui Matos 2012-09-23 02:06:51 UTC
Created attachment 225008 [details] [review]
keygrab: Allow unmodified and synchronous grabs if requested

Unmodified grabs are useful not only for a certain range of keysyms
but calling code has to deal with them specifically so make it
available on explicit request.

Likewise, synchronous grabs are useful as they allow us to replay
events that might be interesting to other applications but also need
special care on the calling side.

This patch changes the API so that both of the above options can be
requested and makes ungrabbing separate from the calling code
perspective.
--

(In reply to comment #46)
> I think this is a problem for the other uses of grab_key_unsafe in
the media
> keys plugin. Try hitting one of the grabbed media keys, and observe
that you
> will loose all keyboard input from then on.

Interesting that I never noticed that here and I have been actively
testing that. But now I think I know why, I was just running make
install on the common, media-keys and keyboard plugins directories and
restarting g-s-d, and I guess that's not enough. It was obviously
enough for the key grabber process since that's an independent
binary...

Anyway,

> How about changing the key grab api a bit more to
>
> GsdKeyGrabFlags {
>   GSD_KEY_GRAB_ALLOW_UNMODIFIED,
>   GSD_KEY_GRAB_SYNCHRONOUS
> }
>
> grab_key_unsafe (Key *key, GsdKeyGrabFlags flags, GSList *screens)
> ungrab_key_unsafe (Key *key, GSList *screens)
>
> This addresses a number of other issues I have with the api and your
changes to
> it:
>
> - Calling the enum GsdKeygrabMode invites confusion with the X
concept of
> GrabMode
>
> - Much better to have separate functions for grab and ungrab, imo

yes this is better and safer indeed. I tried to shuffle the code as
little as possible here to be on the safe side. This time tested the
full g-s-d install and media-keys seems to do its job.
Comment 52 Rui Matos 2012-09-23 02:07:48 UTC
Created attachment 225009 [details] [review]
keyboard: Add modifiers-only shortcuts to switch input sources

--
Rebased and squashed the single modifiers addition since I don't see
much value in having that in a separate patch.
Comment 53 Matthias Clasen 2012-09-23 02:42:32 UTC
Review of attachment 225008 [details] [review]:

Looks good to me.
Comment 54 Matthias Clasen 2012-09-23 02:42:52 UTC
Review of attachment 225008 [details] [review]:

.
Comment 55 Matthias Clasen 2012-09-23 02:43:11 UTC
Review of attachment 225009 [details] [review]:

Looks good to me
Comment 56 Matthias Clasen 2012-09-23 15:17:19 UTC
Got the necessary freeze break approvals on the list
Comment 57 Rui Matos 2012-09-23 15:43:02 UTC
Got release team approval:
https://mail.gnome.org/archives/release-team/2012-September/msg00258.html

Thanks

Attachment 225008 [details] pushed as 45d0ca4 - keygrab: Allow unmodified and synchronous grabs if requested
Attachment 225009 [details] pushed as 4b81759 - keyboard: Add modifiers-only shortcuts to switch input sources
Comment 58 Dimitri 2012-09-25 22:42:35 UTC
Rui and others, thanks a lot for your efforts!

However, could I ask you please for a brief howto on enabling Alt-Shift and similar combinations? g-c-c still doesn't accept such combinations, and setting org.gnome.settings-daemon.plugins.media-keys switch-input-source = "<Alt><Shift>" makes g-s-d segfault, like it did before.

gnome-control-center 3.6.0, gnome-settings-daemon 3.6.0, Mageia Linux (Cauldron)
Comment 59 Rui Matos 2012-09-25 23:02:20 UTC
(In reply to comment #58)
> However, could I ask you please for a brief howto on enabling Alt-Shift and
> similar combinations? g-c-c still doesn't accept such combinations, and setting
> org.gnome.settings-daemon.plugins.media-keys switch-input-source =
> "<Alt><Shift>" makes g-s-d segfault, like it did before.

For the time being the UI for this shortcut is going to be in gnome-tweak-tool which should get a new release some time soon.

For now you can set the gsetting manually but it's not the one you tried. Try this instead:

$ gsettings set org.gnome.settings-daemon.peripherals.keyboard input-sources-switcher alt-shift-l
Comment 60 Yotam Benshalom 2012-09-30 21:41:09 UTC
Another related issue: the Menu key (next to the right control) can be set in the UI as a trigger to change layouts, but it no longer works. It only pops the right-click menu when pressed.
Comment 61 Dimitri 2012-10-01 18:21:15 UTC
Rui, thanks again, everything seems to work now. However, I have discovered that individual keyboard layouts are not maintained for applications/windows anymore. This feature was extremely convenient in previous versions of GNOME. Just wanted to know, is this intentional feature removal, or is it just an ordinary regression that is going to be fixed? Thanks!
Comment 62 Rui Matos 2012-10-02 13:44:50 UTC
(In reply to comment #60)
> Another related issue: the Menu key (next to the right control) can be set in
> the UI as a trigger to change layouts, but it no longer works. It only pops the
> right-click menu when pressed.

Please report different issues in different bugs.
Comment 63 Rui Matos 2012-10-02 13:45:18 UTC
(In reply to comment #61)
> Rui, thanks again, everything seems to work now. However, I have discovered
> that individual keyboard layouts are not maintained for applications/windows
> anymore. This feature was extremely convenient in previous versions of GNOME.
> Just wanted to know, is this intentional feature removal, or is it just an
> ordinary regression that is going to be fixed? Thanks!

See bug 684210.
Comment 64 Roman 2012-11-06 10:11:20 UTC
> $ gsettings set org.gnome.settings-daemon.peripherals.keyboard
> input-sources-switcher alt-shift-l

Ше вщуы
It dues not work then in gdm!
Comment 65 Rui Matos 2012-11-06 14:20:38 UTC
(In reply to comment #64)
> > $ gsettings set org.gnome.settings-daemon.peripherals.keyboard
> > input-sources-switcher alt-shift-l
> 
> Ше вщуы
> It dues not work then in gdm!

Right, because we don't have a way to export gsettings into a system-wide store yet. You can set it for the 'gdm' user running that same command prefixed with 'sudo -u gdm '.
Comment 66 mads 2012-11-08 18:58:15 UTC
These changes cause quite a bit of confusion elsewhere. I found this issue but it took some time to get the bigger picture explained for dummies. Summarizing my learnings:

A 'normal' keyboard shortcut for switching keyboard layouts can be configured in
the control-center and stored in org/gnome/settings-daemon/plugins/media-keys switch-input-source . That method can however not handle 'dead' key combinations.

This patch is thus about adding another method for other key combinations. It can be configured in gnome-tweak-tool or stored in org/gnome/settings-daemon/peripherals/keyboard input-sources-switcher. The available values can be found in /usr/share/glib-2.0/schemas/org.gnome.settings-daemon.enums.xml under GsdInputSourcesSwitcher .

Despite other claims I am very sure there used to be a default X key combo, shift+capslock. Now there is no default key combo and there is currently no way to configure shift+capslock. Bug 686613 do however have a patch that makes it possible to configure input-sources-switcher='shift-caps'.
Comment 67 Goran Rakic 2013-02-28 14:59:52 UTC
Sorry for using this bug for discussion, but is it possible to use lwin key (left super key) for switching keyboard layouts?