Nowadays I have configured two keyboard layouts (English and Russian) on 18.04 LTS with all updates. Here I set Ctrl+Shift as keyboard layout switcher.
But I unable to use my keyboard layout switching shortcut - it has interference with other shortcuts, which are started from Ctrl+Shift+…: Ctrl+Shift+T, Ctrl+Shift+C and Ctrl+Shift+V in mate-terminal, Ctrl+Shift+arrows in text editors and so on.
I reported bug about that on LaunchPad (see bug 1720364). It is reintroduction of other well-known bug 1245473.
If you dedicate two modifier keys as input source switcher, isn’t it natural that other key combinations which include those keys won’t work? Otherwise, how would the desktop know if you want to switch input source or do something else?
If you want preset key combinations involving Ctrl and Switch to work, use something else for switching input sources, for instance the default Super + Space.
For better understanding I’ll include two screenshots here: one from GNOME 2.32.1 (the best GNOME release from 2010, frozen on my Gentoo system) and MATE DE 1.12.1 (current version from Ubuntu Xenial Xerus 16.04 LTS).
Both of them contain shortcuts with two modifier keys. I expect that all these keyboard combinations work without problems. This functionality exist many-and-many years.
I understand that modern GNOME developers are adored by Apple products with their Super+Space, but not all Apple ideas are good. Even modern Windows 10 allow user to set traditional Alt+Shift and Ctrl+Shift shortcuts.
In my opinion Super+Space is not good keyboard shortcut for layout switching when working with long bilingual texts.
But why conventional layout switching is broken?
And what is interesting, ubiquity installer sets Alt+Shift (XKBOPTIONS="grp:alt_shift_toggle,grp_led:scroll" in /etc/default/keyboard, see bug 1270574).
I sincerely ask you to pay attention to keyboard layout switching problems.
I think your expectation is the problem here. You never answered the question I asked:
How would the desktop know if you want to switch input source or do something else?
Please do.
For instance, I can use Ctrl+Shift to switch to the next input source on my Ubuntu 17.10. It works. But then Ctrl+Shift+<somekey> key combinations don’t work. I see that as a natural consequence of the fact that I chose a shortcut which conflicts with preset shortcuts, while you see it as a problem.
How would the desktop know if you want to switch input source or do something else?
OK, I’ll answer.
It should simply interpret hotkey combination on KeyRelease event (when key is up) and not on KeyPress (when key is down).
On 16.04 LTS with MATE DE hotkeys seem to be interpret this way.
On 17.10 and 18.04 LTS it does not.
So I reported bug about that to upstream. I hope that @Wimpress will help to solve this issue.
The layout switching menu provided by GNOME Tweaks is a GUI interface to set the corresponding XKB options. So to get the functionality you would like to see, I suppose that the behavior of XKB would need to be changed. Would that be reasonable? Can’t really tell, but I fear it’s hard to make developers give it high priority.
You say that it works that way on 16.04 with MATE, and if it does, this may not be an XKB thing after all. AFAIK XKB hasn’t been changed in this respect lately.
Thanks for making this available, @Norbert. Great work!
Just wondering: There must be reasons why this hasn’t been fixed upstream. Is there a risk for side effects which people who use your PPA should be made aware of?
I do not know why it is not fixed upstream.
The patch I used is developed by ArchLinux user kyak.
And it seems that even they can not pull it upstream too.
@Norbert, great! Thank you for your efforts!
I confirm that this patch fixes the problem for me. I have just tested it in LO Writer in Ubuntu 18.04.
I use ‘Alt + Shift’ as keyboard layout switcher and, lately, the shortcut in LO Writer ‘Shift + Ctrl + Alt + V’ (yes, I used to use this shortcut regularly) hasn’t been working. Now, after update from this PPA, it works again as expected.
You could try to submit the patch as a Stable Release Update but it will almost certainly not be accepted because Xorg is such a critical part of the OS. Nice one on requesting it for Debian 10, I’m guessing that it’s too late for Ubuntu 18.04 but we’ll have to see what Debian make of it because if they accept it soon then it’ll be in Ubuntu 18.10…
It’s not perfect. But It never was and Ubuntu carried it for 5 years. Alternate solutions has been declined on upstream as well. They are very stubborn.
My issue is key press vs key release. Ubuntu carried the xorg patch mentioned above since 12.04. Then they dropped during 17.10 because it didn’t apply correctly. However Arch has updated the patch (even on upstream) and @Norbert is using it. I don’t see any reason why it can’t go in Ubuntu as FFE as of now or as SRU later. It actually solves couple of shortcuts issue in Unity too. @jbicha ?
The patched packages (with patch from AUR) was tested and work great in:
Ubuntu 16.04 LTS (with HWE) - Unity, MATE, Xfce;
Ubuntu 18.04 LTS - KDE, MATE, Xfce.
I completely do not care about GNOME, I even not tested patched packages with it.
GNOME “developers” break normal classic user experience, so I ignore them.
I can’t fix the patch, because I’m not an author of it.
If you guys are so clever, you can ask support here, or on Xorg (and wait another 5-10 years), or on IRC, and write your own pretty good nice patch.
You can also patch GNOME Shell, Mutter, Metacity, Compiz and whole Xorg stack if GNOME fails for you.
I need to do my main work, I do it in MATE DE.
So I made my life easier with packages from my PPA.
Now I can use MATE on 16.04 LTS (with HWE) and 18.04 LTS. Nothing more.
If my packages do not help you - you can always remove the PPA with
CapsLock is the most simplest key for changing layout when you want to work with both hand while writing a mixed text of two language. Actually CapsLock does not use to its main function because people barely write with a lot of bold words and using shift for occasionally one letter is very common,
Yet CapsLock does not seem to be configurable for this task for me on 18.04.1. It did work on 17.10 Does it work for you? If it does what is your setup?
replying to myself - after the application of the suggested patches I have managed to configure CapsLock to work - Put the “CapsLock behaviour” in “Advanced Layout Options” into “disabled” (not “CapsLock disabled” which is another setting available there, sic!) And then went to dock icon keyboard layout settings and just set CapsLock in “Switch to next source using”
I have also activated “Show Extended Input Sources” but not sure if that’s required.
