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.

I agree with Elad. this would be a big drawback of the desktop's usability for multilang users.

Also see discussion in bug 666393; and especially bug 669742 comment 2.
Probably a duplicate.

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 ***

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.

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.

*** Bug 682349 has been marked as a duplicate of this bug. ***

(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.

This should be a blocker for 3.6.

Sorry for meaningless comment, but that's a horrible drawback. Please fix this.
P.S. Maybe it's time to change status at least?

This should be considered as a blocker bug. I really liked this dialog.

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.)

> 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?

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.

(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 :)

Rui, Bastien, this is really highest-priority blocker for Russian users (at least - but I suspect other languages are affected)

(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.

The Importance of that bug is still "Normal"/"normal". That's what caused my previous comment.
Apologies for not looking into blocker list @ddl

(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

Thank you! The Russian community got agitated by that regression, now at least people can be relieved, their voice is heard.

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.

> 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.

(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...

Will it be less hacky to do so if/when https://bugs.freedesktop.org/show_bug.cgi?id=865 is fixed?

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.

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.

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.

(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).

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?

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.

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.

Rui, BTW, if you are going to fix it for Caps, could you please add switching by RCtrl - that is what I am using.

(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.

One combo??? There are multiple GROUPS of options. Some of them allow multiple selection, some don't.

(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

sorry I meant all xkb options that were available in 3.4

(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.

(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.

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 ?

(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.

Other combinations (unrealted to this patch) and media-keys don't work in the overview either, see bug #643111

Created attachment 224998 [details] [review]
keygrab: Do a synchronous grab on the master device

--
Just rebased.

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.

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.

Created attachment 225001 [details] [review]
keyboard: Add single modifier shortcuts to the input sources switcher

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

Review of attachment 225000 [details] [review]:

See my earlier api comments

Review of attachment 224999 [details] [review]:

This looks fine to me

Review of attachment 225001 [details] [review]:

Looks fine to me

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.

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.

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.

Review of attachment 225008 [details] [review]:

Looks good to me.

Review of attachment 225008 [details] [review]:

.

Review of attachment 225009 [details] [review]:

Looks good to me

Got the necessary freeze break approvals on the list

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

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)

(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

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.

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!

(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.

(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.

> $ gsettings set org.gnome.settings-daemon.peripherals.keyboard
> input-sources-switcher alt-shift-l

Ше вщуы
It dues not work then in gdm!

(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 '.

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'.

Sorry for using this bug for discussion, but is it possible to use lwin key (left super key) for switching keyboard layouts?