linked to https://bugs.launchpad.net/ayatana-design/+bug/929476 on launchpad

(In reply to comment #0)
> Inside 'Control Center/Keyboard Preferences/Options (keyboard Layout Options)'
> there is an option to enable keyboard layout switching using the ALT+SHIFT
> shortcut.

Where exactly under System Settings > Keyboard > Shortcuts?

> See attached image keyboard_layout_options.png.

That attachment is missing.

(In reply to comment #0)
> Note that this change should not be made until bug
> https://bugs.launchpad.net/xorg-server/+bug/36812 is also fixed.

No, you meant https://bugs.freedesktop.org/show_bug.cgi?id=865 . 
This is upstream and not about one distro.

Also see bug 668802.

Actually GNOME automatically enables Caps-shift if the number is layouts > 2. grp:shift_caps_toggle. Does that work?

Seems as simple as setting a default for switch-input-source and switch-input-source-backward and leave it up to applications to handle the combination if we don't have > 1 input source.

What is the current default layout switching combination in GNOME? bochecha on #fedora-desktop told me it's ctrl+space, but comments in this bug seems to indicate that there is no default keyboard layout switching combination at the moment.

If you want to make the default alt+shift (which I'm highly in favour of), then you'd probably need to wait for the patches from bug #681685 to be reviewed and pushed

(In reply to comment #5)
> What is the current default layout switching combination in GNOME? bochecha on
> #fedora-desktop told me it's ctrl+space, but comments in this bug seems to
> indicate that there is no default keyboard layout switching combination at the
> moment.

There isn't any, and we won't be using Alt+Shift as the default until the architecture for handling it is less crappy...

(In reply to comment #3)
> Actually GNOME automatically enables Caps-shift if the number is layouts > 2.
> grp:shift_caps_toggle. Does that work?

That also used to be my experience. As all other keyboard shortcuts it is possible to get used to anything but changing is hard.

And no, grp:shift_caps_toggle does not work because GNOME no longer uses XKB that much and doesn't set that option ... and XKB no longer knows which layouts are configured, so setting the option would not help.

Changing the default keyboard shortcut to some other combination might make sense, but please don't change it more often than necessary. Please:

1. make sure there is _some_ default key combination for switching layouts
2. please try to preserve the existing user experience unless it is a deliberate choice to change it.

Please make input-sources-switcher default to 'shift-caps' after the patch in bug 686613 has been applied.

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

Input method seems to be a system level thing, so I'd really recommend sticking to Super for the default. I believe OS X uses Super+Spacebar, which seems to be very affordable/reachable.

Jakub, in MSWin/X11 world peope used to switching using modifiers ONLY. One of the most annoying things in MacOS for me personally was inability to have "modifiers only" layout switching.

Also, in MacOS there is a trouble - Super+Spacebar is also used by the Spotlight. There is clear conflict here (have to disable that shortcut for Spotlight explicitly every time).

I'm not speaking against using modifiers alone. They would be good to have for those accustomed to it. I'm only suggesting a default. The conflict you speak of is not relevant in our case.

I am saying that default switcher should be of "least surprise". Alt-Shift would be the best choice in that case (even though I am used to RCtrl).

I have recently upgraded my GNOME desktop to 3.6 and the changes discussed here were the most nasty surprise of all. It took me two full days and a lot of googling to discover that it is still possible to switch the layout by pressing that ridiculously strange combination of Ctrl+space. It is so inconvenient that I prefer to use gxneur (automatic layout guesser), which often replaces shell commands with nonsense Cyrillic strings.

I am used to the RCtrl switch and press it unconsciously even with the automatic guesser. Unfortunately the new config dialog does not allow to set it as the layout switch hotkey. Please, make it possible! 

Alt+Shift is very popular in Russia and Belarus and indeed makes a good default  for Cyrillic languages, but other options (Cannot type them because autoswitcher thinks that I try to enter something in Russian and replaces names of the keys) should be supported as well.

(In reply to comment #13)
> It took me two full days and a lot of
> googling to discover that it is still possible to switch the layout by pressing
> that ridiculously strange combination of Ctrl+space.

That's probably a sign that we should cover this in http://library.gnome.org/users/gnome-help/3.6 (or in case it's covered that it's not easily discoverable). Could you file a bug report against https://bugzilla.gnome.org/enter_bug.cgi?product=gnome-user-docs&component=gnome-help ? Thanks!

I would just set the keyboard shortcut by default - that way we can advertise it in region and language > input sources even if there is only one input method/keyboard layout.

(In reply to comment #14)
> That's probably a sign that we should cover this in
> http://library.gnome.org/users/gnome-help/3.6 (or in case it's covered that
> it's not easily discoverable).
I think that it is still premature to write a documentation about something that has to change ASAP. There might even be no need to document anything if the hotkey will be 
a) chosen so as to be already familiar to the user (There is a limited set of the most common hotkeys for each country).
b) immediately visible in the config dialog called by right-clicking the layout indicator.

My main point was that the default combination chosen is extremely strange and the current version of the layout switch hotkey setup dialog is unusable because it does not allow the user to specify any of the common/traditional switch hotkeys in Russia/CIS:
- Control+Shift
- Alt+Shift
- Right Control
See the excellent keyboard configurator from Gnome 2.2x for more options. 

If any software wants to use hotkeys tat conflict with THIS, the software must shut up and suffer. Switching layouts is a subconscious action often engraved into the user's lower brain by many years of typing. There is a tremendous inertia of habit here. You cannot change it by setting any arbitrary combination and documenting it. 

> I would just set the keyboard shortcut by default - that way we can advertise
> it in region and language > input sources even if there is only one input
> method/keyboard layout.

I would also like to make a suggestion here. The best default layout switch combination is different for different locales. If the user has not indicated his/her preference before, it should be preselected depending on locale.

// While reading some bug reports I saw that the Control+Space combo was justified by the same kind of habit of CJK users from Far East. Those languages have very different writing systems from Greek/Cyrillic etc. The software supporting input of different languages evolved independently and multiple different traditions formed in different countries. It is technically easy to choose the default hotkey depending on the locale.  E.g. If the locale is Russian, choose Alt+Shift as the default (and offer an easy way to change the hotkey to Right Control etc.). If the locale is Chinese, choose what the Chinese are mostly used to. 




Therefore 
  performed thousands of times per day and  
(In reply to comment #15)

We should also ensure that a <super> shortcut is enabled by default (see bug 689967). super+space seems like the best option for this.

I'm a long term Russian user of Linux and Fedora (since RH5 at least), and I've been using "both shifts" combination for 18 years. Please provide enough flexibility to preserve various combinations, like

"both shifts"
"left shift + left alt"
"left shift + left control"

at least - as far as Russian layouts go.

It is TOTALLY UNACCEPTABLE to FORCE some ad-hoc combination like "left control + space" or "left shift+caps lock" as a new "standard".

Thank you,
V.L.

This was the most annoying problem of 3.6. Here in my country it's common to use "Alt + Shift" for changing layout. In 3.6 we used gnome-tweak-tool to make "Alt + Shift" for changing layout. While gnome-tweak-tool solved that problem, it introduced another one that was the weakest point of 3.6. It had a delay while changing layouts. When you were typing fast and change layout, some characters was from the previous layout. I know many many many people around me that leaved gnome and 3.6 just because of this annoying delay and the complexity of defining layout changer shortcut (Honestly, I don't know why even gnome leaders decided to release input-resources while it was incomplete).

I upgraded to 3.8 today and this problem is not addressed. keyboard shortcuts dialog doesn't let to choose modifiers only keys (Is there any technical reason for that?) and the delay is still there too.

I don't know how to emphasis, to show that this is really a big problem for people. 3.4 had all these functionalities, "Shift+shift", "Alt+shift", "Shift+Control",... why removing all of them and making them to use your "best choice"? I can't even see any logical reason to choose "super+space". "super" is the shortcut to show Activities View, and putting it for changing layout causes it to pops up unintentionally. We change layout every moment, it's the most pressed shortcut for other languages. And pressing "super" with "space" is hard.

Please, Please, Please fix this delay and shortcut problem. I'm coordinator of Persian language and I can't convince people to contribute to a project that doesn't care about my language. My friends have asked me hundreds of time if this delay is fixed in 3.8 or not. It will be a big disappointment.

(In reply to comment #19)

Arash, I am aware of that problem and in fact am working on fixing it as I type this. I should have patches for it shortly that I'll try to get into 3.8.1.

(In reply to comment #20)

Thank you Rui. It's really great to hear that :)

The patch in bug 697002 will finally allow us to use Alt+Shift and other shortcuts configured through the XKB grp: options. So everyone agrees that we should enable Alt+Shift as soon as there's more than one input source?

I think it's a good idea. It's not our main langauge-switching shortcut (as the design proposal says all system-related keyboard shortcuts will involve the Super key), but I see no harm in enabling it by default - and it'll be especially useful for keyboards without Super.

I think the right question should be: Does anyone has any *objection* to enabling alt+shift by default?

From Mongolia.
Since switching layouts is extremely frequent, one key is better. In my company, we use the right Win key for this.

And we use RCtrl for switching layouts. 

BTW. In 1980-s all Russian keyboards had a dedicated hardware button "RUS/LAT" to switch between the keyboard layouts. There often were two symmetrically placed hardware buttons to the right and to the left of the space bar just like "Ctrl", "Alt" or "Win/Super" keys.  

Unfortunately, later the market was flooded by crappy foreign keyboard designs lacking the "RUS/LAT" buttons. All key combinations invented ever since are just poor substitutions. The closest you can ever get now is a single key located at the extreme down row that could be found at both sides of the space bar symmetrically. This leaves the choice between RWin/LWin, RAlt/LAlt or RCtrl/LCtral keys. The R/L Ctrl is located closest to the proper position of the layout swith button and the Win(Super) key is "the most optional". This makes any one key of any pair (depending on the right or left handedness of the user) a good candidates for the permanent layout switch. 

Apparently, the authors of the Gnome UI design never used any language with a non-latin alphabet and were totally ignorant about layout switching and ergonomics of the process.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/179.