I was referred here by Gunnar Hjalmarsson following a question on askubuntu [1] regarding incorrect layout for hotkeys in at least intellij idea and vscode.
In both cases, hotkeys seem to be pinned to the layout corresponding to the first input source declared in the gnome Language and Region settings. For shortcuts ( and for shortcuts only which makes it really painful) the layout doesn't change but normal typing is correctly remapped. I have read through this thread but am still unsure if the issue is - in ubuntu/gnome/linux - in the apps themselves - in my own configuration What I observe : - setup an azerty layout then a qwerty layout (both are latin compatible) - in azerty text typing and hotkeys behave as expected in vscode and intellij - in qwerty text typing behaves correctly but hotkeys are still mapped to the physical keys they would be bound to in the azerty layout - reverse azerty and qwerty in gnome settings - in qwerty text typing and hotkeys behave as expected in vscode and intellij - in azerty text typing behaves correctly but hotkeys are still mapped to the physical keys they would be bound to in the qwerty layout What I expect : - setup an azerty layout then a qwerty layout (both are latin compatible) - in azerty text typing and hotkeys are bound to azerty keys both in vscode and intellij - in qwerty text typing and hotkeys are bound to qwerty keys both in vscode and intellij - reverse azerty and qwerty in gnome settings - in azerty text typing and hotkeys are bound to azerty keys both in vscode and intellij - in qwerty text typing and hotkeys are bound to qwerty keys both in vscode and intellij I tried various combinations of configurations at various layers to try and make this work to no avail for now. my latest config state is in the askubuntu post [1] https://askubuntu.com/questions/1281251/keyboard-shortcuts-do-not- honor-selected-input-source-in-some-apps -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1226962 Title: Keyboard shortcuts (hotkeys) not functional in some cases in non-latin keyboard layouts Status in aptana-studio-installer: New Status in Default settings and artwork for Baltix OS: New Status in LibreOffice: Fix Released Status in ibus: New Status in Indicator keyboard: Fix Released Status in Inkscape: Fix Released Status in Intellij Idea: New Status in monodevelop: New Status in Mutter: Fix Released Status in okular: New Status in OpenOffice: New Status in sigram: New Status in Unity: Fix Released Status in gnome-settings-daemon package in Ubuntu: Triaged Status in gnome-terminal package in Ubuntu: Triaged Status in kdevelop package in Ubuntu: Confirmed Status in mc package in Ubuntu: Confirmed Status in openjdk-7 package in Ubuntu: Incomplete Status in terminator package in Ubuntu: Confirmed Status in unity package in Ubuntu: Fix Released Status in unity-settings-daemon package in Ubuntu: In Progress Status in gnome-settings-daemon source package in Xenial: Triaged Status in gnome-terminal source package in Xenial: Triaged Status in kdevelop source package in Xenial: Confirmed Status in mc source package in Xenial: Confirmed Status in openjdk-7 source package in Xenial: Incomplete Status in terminator source package in Xenial: Confirmed Status in unity source package in Xenial: Fix Released Status in unity-settings-daemon source package in Xenial: In Progress Status in gnome-shell package in Fedora: Won't Fix Status in openoffice package in Fedora: Won't Fix Bug description: Keyboard shortcuts are key combinations like Alt+F (usually opens the File menu) and Ctrl+O (usually opens the File→Open... dialog box). There is an issue with non-latin keyboard layouts that the keys under F or O (for Alt+F and Ctrl+O respectively) would correspond to some other character. What should happen then? There is some smart functionality (at least in the GTK+ library) that when we press a shortcut, it will try to make Alt+F or Ctrl+O work, even if the active keyboard layout is not English. For this smart functionality to work, it requires us to have as first keyboard layout the English (en) layout. Then, GTK+ will be able to check whether the shortcut makes sense for English, and if so, will run it. All that even if the active layout is Greek or Russian or something else. This report has over 300 comments and these comments include all sort of corner cases that indeed shortcuts do not work. In general, shortcuts work, but in specific cases there are issues that need to be fixed. What we need to do, is collect those corner cases and create new separate reports. Here are the corner cases: 1. In Dash (in Unity 7), shortcuts like Super+S/W work (for example, Greek, Russian), but they do not work for Super+A/F/M/C/V. Report: <not reported yet> 2. Java GUI applications on Linux do not support shortcuts in non-latin languages. This is an issue with Java and should be reported there. Java GUI apps are not included in any of the Ubuntu ISOs. Report: <not reported yet> 3. Shortcuts that use Ctrl on LibreOffice work for several languages (like Greek, Russian), but has been reported not to work on Hebrew. This should be a separate bug report specific to Hebrew and other languages affected in the same way. Report: <not reported yet> To manage notifications about this bug go to: https://bugs.launchpad.net/aptana-studio-installer/+bug/1226962/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp