Guake does not respect keyboard layout anymore

[hydrargyrum]

Describe the bug

I have 2 keyboard layouts (configured using my desktop environment): french azerty and french bépo (dvorak-like).
When I use a keyboard shortcut, it acts as if I were in the main layout even if I'm using the secondary layout.

I'm guessing the same issue would occur with qwerty and dvorak.

For example I use Ctrl-Shift-C for copying text. But when I press it, it opens a new guake tab, as if I had typed Ctrl-Shift-H. The C key in secondary layout is in the location of H key in the main layout. So it seems guake uses the position of keys of main layout even though the secondary layout is selected.

It used to work with previous guake versions, I'm not sure which version I had previously when it worked (maybe 3.8.1).

Expected behavior

Guake uses the actual keysyms pressed, and the correct shortcut is triggered.

Actual behavior

Guake uses the keycodes pressed, and translates them to keysyms using an incorrect layout, triggering incorrect shortcuts, or not triggering anything because the wrong key was interpreted by guake.

To Reproduce

• Have configured 2 keyboards layouts significantly different
• Use the secondary layout
• Press any keyboard shortcut

---

$ guake --support

Guake Version: 3.8.5

Vte Version: 0.67.90

Vte Runtime Version: 0.67.90

---

GTK+ Version: 3.24.33

GDK Backend: <GdkX11.X11Display

---

Desktop Session: xfce

---

Display: :0.0

RGBA visual: True

Composited: True

• Monitor: 0 - SAM HDMI-0
  • Geometry: 1920 x 1080 at 0, 0
  • Size: 160 x 90 mm²
  • Primary: True
  • Refresh rate: 60.0 Hz
  • Subpixel layout: unknown

[Davidy22]

Was able to reproduce, working on a fix

[Davidy22]

So I've been working and investigating and learned some stuff about the cyrillic alphabet that was the reason for #1953. In the initial report in #1946, user @vantu5z requested that keybindings be essentially layout agnostic, I thought that the english letter C and Russian letter C were equivalent when I first read the bug report but the Cyrillic C is apparently an S according to sources I'm seeing and every conversion tool I tested.

The merged patch to resolve that issue switched Guake over to looking at scancodes instead of key values. Scancodes are fixed position, and Guake sets up keyboard shortcuts at startup so if the user switches between keyboard layouts after Guake starts up Guake won't follow the change in layout because the shortcuts are position bound after #1953. This is probably incorrect, so we probably have to switch back to comparing some equivalent of the key value. This reintroduces the issue with the Russian keyboards though, because particularly in the example given in the other bug report, Ctrl+Shift+C would actually be impossible on a Russian keyboard because 'С' isn't a C and there isn't actually a single key that directly translates to C so we need to find some different scheme for converting Cyrillic key values to registered english shortcuts. Now looking up clean ways to convert non-English alphabet characters to their equivalent position on a qwerty keyboard, because I think that's better than trying to translate characters and effectively require rebinding shortcuts if you're switching to a keyboard with non-latin characters.

Final fix will probably look like a reversion of #1953 and insertion of some layout conversion code for the non latin characters.

[vantu5z]

For more understanding add some pictures of keyboard layouts:
azerty / bépo

qwerty / йцукен

For my opinion key bindings should be connected to physical keys, to avoid position changes on layout switch. Usually we use mechanical memory when use key bindings and don't look every time which layout is set (and don't read letters on keys).
Also you choose key binding that comfortable to access preferably by one hand (for example you don't choose Ctrl+Shift+4 for some frequently use function).
Some keyboards has labels on keys like copy, paste and etc. And if them will work only in some layout it was strange.

So if we go back to layout dependent key bindings we get the same issue but from other side:

1. As your example (with same letters in different places): some one will miss layout and get incorrect functions.
2. Some key bindings will not work at all (no letter in this layout).

Another question how them should be represented in config dialog. For now key bindings dialog is misleading for symbols which looks identical in different layouts.

[Davidy22]

Well looks like we got some contention in here, I actually just finished writing the fix I proposed and came back here to comment, some hacky bits to it though. It reverts back to checking key values instead of scancodes, and in the case of characters like in Cyrillic it pretends the layout is the first available latin character set keyboard configured on the machine. This does introduce the moving keyboard shortcut behavior when switching between qwerty/dvorak/azerty etc which looks like there's some disagreement about on here.

From what I gather, reporter wants keyboard shortcuts to follow the layout, we also got someone who wants keyboard shortcuts to remain static across layouts. If we're going with the latter then I assume that means I'd tag wontfix and close this and my patch, although I do see a fair bit of merit to having a registered CTRL+C correspond to actual C on the keyboard for learners and for configuring keybindings.

[vantu5z]

Maybe we don't understand reporter. And @hydrargyrum just can't configure keybinding he want (in config dialog see Ctrl+Shift+C, but actual have Ctrl+Shift+Y(c)). I can't belive that someone want to have floating keybindings.

Also it should be similar to Gnome keybinding ecosystem. Does usual Ctrl+C (for copy) in system edit fields (text editors and other) follow the layout and changes from Ctrl+Y(c) to Ctrl+C(h)? If so, we should apply your patch. As for me (en/ru layout) I don't feel any change, as all Cyrillic symbols has own keyvalues. Maybe only some special symbols will be effected.

[Davidy22]

I just tried hitting CTRL+C, CTRL+V with dvorak and it copied and pasted with the global gnome clipboard so looks like general gnome follows key values.

[hydrargyrum]

I can't belive that someone want to have floating keybindings.

Actually, it makes sense when there are 2 users sharing the session and using different keyboard layouts. The 2 users press Ctrl+Shift+C, but the physical keys they press are in different locations.