Keybindings assume specific keyboard layout (Linux, 0.9.0) about extraterm HOT 9 CLOSED

I've been vaguely aware that my keyboard handling was wrong and probably broke on other layouts. I'll give this problem some prio. I need to go fix the Alt key handling too.

from extraterm.

Fixed in v0.11.0.

from extraterm.

So, I'm seeing that you made things more consistent in 0.11.0. Unfortunately, you made it consistently wrong.

In 0.9.0, if I type in a partial command and hit Ctrl+C, the shell receives the input and clears the command. In 0.11.0, I have to type Ctrl+J to get the same behavior (because the key that would produce 'c' in a US QWERTY layout produces 'j' in Dvorak).

Meanwhile, if I attempt to create a new tab with Ctrl+Shift+T, that fails in both 0.9.0 and 0.11.0. In both cases, I have to use Ctrl+Shift+Y because the key that produces 'y' in my layout produces 't' in US QWERTY.

from extraterm.

Thanks for testing. I swear I've had this working correctly (using Kubuntu 16.04 and dvorak) but something is clearly wrong now. It is going wrong here too.

from extraterm.

I've had a look at this a bit it is Linux specific. On Windows and MacOS, Electron sends the correct values in its KeyboardEvent even when Control is used. On Linux Electron is using the untranslated key code.

This is something which needs to be fixed up in Chromium itself.

from extraterm.

Atom, which also uses Electron, gets it right, so the problem is not insuperable in user code. They aren't detecting dvorak and mapping it manually; I'm using a custom layout based on dvorak. They aren't reading data files out of /usr/share/X11/xkb.

from extraterm.

That is an interesting point.

I just had a look in the Atom code and it appears that they have a native module (https://github.com/atom/keyboard-layout) which does let Atom spy the selected keymap in the OS. In another module atom-keymap (https://github.com/atom/atom-keymap) they do actually manually detect Dvorak and translate the keypresses. It is all pretty gross really.

I'm using the (new) 'key' field in the KeyboardEvent which is supposed to clean up this mess, but as we see it is buggy on Linux.

from extraterm.

This Chromium bug should have fixed the problem with KeyboardEvent.key but it didn't. https://bugs.chromium.org/p/chromium/issues/detail?id=227231

A bug report which matches what we are seeing is here: https://bugs.chromium.org/p/chromium/issues/detail?id=585241 and I've updated it with the current state of play.

from extraterm.

I had a good look at what they are doing in Atom. Selectively grabbing the value out of KeyboardEvent.keyIdentifier seems to do the trick on Linux, So I've added code for that and tested on Linux.

from extraterm.