Disconcerting error with keymaps/layouts (Colemak) and plugins

I have some disconcerting problem when trying to configure my Keyboardio layout to type emojis more easily. I use Colemak, but I leave the default QWERTY layout in Keyboardio, and then change the keymap in the operating system (I’m using Elementary OS at home).

I’m using the Unicode plugin to type the emojis, and I had to change the Ctrl-Shift-U which is pressed by the plugin (on Linux) to Ctrl-Shift-I so it worked. The reason is that in Colemak, the key labelled “I” in most keyboards (ie. QWERTY) produces the “U” I need.

That’s annoying but somehow expected. However, there are two things that really confuse me:

  • Some of the emojis have an “F” in the hex code to type to get them, and they are typed correctly. I would have expected that it would fail, because the key labelled “F” on QWERTY actually produces a “T” in Colemak. How come that works, but the Ctrl-Shift-U doesn’t?

  • When I try to compile the same firmware at work (same versions of everything firmware-related, as far as I can tell, although different OS), the behaviour is different. If I recall correctly, Ctrl-Shift-U is correctly pressed, but the “F” in some of the emojis becomes a “T”, and then the emoji doesn’t work (it works when I switch to a QWERTY keymap in the operating system).

Anyone has any idea how to reliably send key events for certain letters, instead of depending on the current keymap/layout of the keyboard?

It might be possible that in one case, the operating system switches to QWERTY when in unicode input mode, while in the other case, it stays in Colemak. That’d adequately explain the situation.

What operating systems do you use at home and at work? (Though, it is likely the desktop environment, or the input method that’s at play here…)

1 Like

Oh, I didn’t think of that possibility. At home I’m using Elementary OS, and at work I’m using GNOME (RHEL8).
So, that sounds like there’s probably no DE-independent solution? :cry: