Issue
Ctrl+Shift, configured to switch keyboard layout, blocks terminal hotkeys.
Steps to reproduce
Expected behaviour
The action should succeed.
Actual behavior
The action fails, a ^ sequence is inserted instead.
You're just going to have to choose a shortcut that doesn't interfere with your typical workflow for now. The way these shortcuts are managed needs to be completely changed to go thru the window manager - along the way we'll likely make it so you just teach the shortcut you want to use, rather than choosing from a list. Even with that, a global shortcut (such as for switching layouts) will always potentially preempt an application's shortcut.
I cannot reproduce the alt-shift one, btw, even with electron apps (atom, slack) - not sure why.
You're just going to have to choose a shortcut that doesn't interfere with your typical workflow for now. The way these shortcuts are managed needs to be completely changed to go thru the window manager - along the way we'll likely make it so you just teach the shortcut you want to use, rather than choosing from a list. Even with that, a global shortcut (such as for switching layouts) will always potentially preempt an application's shortcut.
I cannot reproduce the alt-shift one, btw, even with electron apps (atom, slack) - not sure why.
What I noticed with the Alt+Shift one is that Alt+Shift+Tab no longer functions, it scrolls forward as if you did not press Shift down.
Looks like the action is bound to keypress itself, and not for it's release.
Hello. I use Ctrl+Shift to switch keybord layout (many years), in our favorite IDEs or editors (like Atom, IntelliJ IDEA) Ctrl+Shift+Z is a REDO shortcut, Ctrl+Shift+K - Push shortcut, Ctrl+Shift+c/Ctrl+Shift+v -copy/paste, Ctrl+Shift+F - find in project... https://github.com/nwinkler/atom-keyboard-shortcuts - instead of a thousand words. but i press Ctrl+Shift+Z and it just change keybord layout, not redo. Why before upgrade to LM19 with Cinnamon 3.8.9 Ctrl+Shift shortcut worked normally, but now we must "going to have to choose a shortcut that doesn't interfere with your typical workflow for now."?
Not sure why that is. I'm 99% certain, however, that we changed nothing on our end that might have caused this. When you upgraded to mint 19, you also upgraded 100's (or even 1000's) of other packages as well, which we have no control over, and we don't necessarily find every little regression that might be caused by another package, directly or indirectly by some behavioral change that causes our code to no longer function as expected.
I'm merely stating a workaround for now, and what in my opinion is the best way forward for this. It does look as though the handling was moved to key-press rather than key-release, as @StubbyKiller stated - at least by checking 18.3 in virtualbox. I'll try to find out what caused this.
This looks like our issue: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1683383
Dup: #7664?
Thx.
Thx.
Most helpful comment
This looks like our issue: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1683383