Layout toggling does not work correctly.

[arsenypoga]

Tried switching layout to colemak and noticed that some of the inputs are displayed in their QWERTY positions.

Here's input from QWERTY keyboard, on a Colemak layout, you can see that the keys are highlighted in order, even though E should have been highlighted on the home row.

Here is the Colemak keyboard with the "QWF" motion. You can see that instead of the F being highlighted in the top row, it's highlighted as a T (that's where the F is located at on the QWERTY layout.

[aradzie]

Thanks for the detailed report. You even recorded a video, that helps a lot. Can you please tell if your keyboard has a hardware switch to toggle between different layouts?

I think I've seen such a behavior before.

For a typical, dumb keyboard it works as follows.

1. You press a key on the keyboard.
2. The keyboard sends to the OS the physical location of the pressed key, roughly speaking row and column number.
3. The OS uses an internal table to map the physical location to a character code. This table is called a keyboard layout. You can configure your OS to use different layouts to generate different characters from the same keyboard keys. Multilingual users know this well. This is how you can use the same keyboard to input text in different scripts, like Latin, Hebrew, Cyrillic, etc.
4. The OS sends the physical key location and the character code of the current layout to keybr to display it on the screen.

In keybr we have the emulation option. When enabled, it ignores the character codes reported by the OS and uses an internal table to map physical key locations to character codes. This option removes the need to switch the keyboard layout in your OS.

Now, there are smart keyboards that have customizable profiles and hardware switches. They work differently.

1. You press a key on the keyboard, which is configured for the Colemak layout in hardware. The keyboard assumes your OS is configured with the Qwerty layout.
2. The keyboard remaps the physical key location of a key in Colemak to the physical key location of the same key in Qwerty and send it to the OS.
3. The OS processes it as if a normal Qwerty keyboard was attached. The OS then produces a correct character code, however, the physical location is completely wrong.

This is a clever trick which works because the absolute vast majority of applications don't care about physical key locations. However, keybr is an exception.

If you really have such a keyboard, I recommend switching it to the Qwerty mode and configure layouts in the OS instead.

That being said, I think I can add an option to keybr to undo the hardware emulation that I described above.

[arsenypoga]

The keyboard I have is indeed "smart" and it's layout it set to Dvorak. The nice thing about smart boards, is that I can just switch out a physical keyboard or have two different keyboards attached and have two separate layouts available at the same time.

That being said, I think I can add an option to keybr to undo the hardware emulation that I described above.

I thought that's what the "Emulate Layout" toggle was for in settings, but it seems like it has no effect.

[aradzie]

I thought that's what the "Emulate Layout" toggle was for in settings, but it seems like it has no effect.

Hmm, no. Unfortunately we don't go as far. The emulation option that we have in keybr assumes you use a typical, dump keyboard. It allows you to practice Dvorak/Colemak in an OS that was configured with any layout. But it cannot undo the hardware remapping like your keyboard does.

To support your keyboard we need a new checkbox, smth like "My keyboard layout is configured in hardware".

[aradzie]

After giving it a second thought, maybe I should remove the existing emulation check box, the one that confused you, and simply keep the emulation option always on. It would be easier for the users, less options to tweak, and the application always works regardless of the OS settings.

Then what's left is the new check box for the smart keyboards. Let me think about it.

[arsenypoga]

There is another reason why this would be a nice addition. Location based key reading only works for defined keyboard layouts, and would not work correctly with more exotic ones like Colemak DH, Azerty and others.

[tommyblue]

same problem here, my keyboard is "smart" 😢

[torbengb]

I noticed the same issue today. Only the highlight effect on the on-screen keyboard is affected and the actual lesson works fine.

Notably, I am using a plain old dumb Logitech keyboard, nothing smart about it. So I do not think this issue has anything to do with "smart" keyboards. The new linked issue #113 has more details.

[josephharney]

I have this issue as well with a smart keyboard. I am happy to contribute a fix if it is the correct direction to go. I am a little confused why a separate toggle would be needed for "smart keyboards".

It seems like there are two features that should be tied together here. The actual key registered in the lesson which is either the correct one advancing to the next character in the lesson or an incorrect one which does not advance and turns the current character in the lesson red. The other feature is the highlighting of the currently pressed key on the keyboard. I would think these features would track together based on whether the Emulate Layout checkbox is checked.

If the emulate layout checkbox is checked:
The remapping of a "dumb keyboard" seems to work properly for both of the above features. I can ignore the letters on my dumb keyboard and type in an alternative layout. I can use the 's' key on my us layout dumb keyboard to advance the lesson when its requesting an 'r' key press. the left index finger key is properly highlighted white on the key press and the lesson advances registering the R letter.

If the emulate layout checkbox is unchecked:
On a dumb keyboard I can type the lesson out on the native qwerty layout even when colemak-dh is selected for the onscreen layout. That makes sense based on my understanding of the "Emulate Layout" checkbox. If I type the 's' key on my dumb qwerty us keyboard the left index key on the screen (labeled with an r) is highlighted and the letter 's' is registered with the lesson. I do not think that I should have "Emulate Layout" unchecked when using a dumb keyboard.

If the emulate layout checkbox is unchecked:
On a smart keyboard I believe this is the reason we have the option to turn off "Emulate Layout". I would expect both of the above features to track together. I can see when I type on a smart keyboard the left index finger on the home row registered the letter 'r' in a lesson on the keyboard configured for colemak-dh. However I see the 'p' key is highlighted on the screen. I understand why that is, but I would think with the "Emulate Layout" unchecked the highlighting would have to be remapped.

I see above a mention of a second checkbox for smart keyboards, but as far as I understand the intention of the emulate layout feature we should only need one checkbox. People with smart keyboards mapped to the same layout as the lesson's layout can unselect the checkbox. People using a standard layout dumb keyboard can use emulate layout. I am interested in contributing a patch for this, but because of the mention of a second checkbox needed I want to make sure I am not missing something about how this should work.

[aradzie]

We have a new settings option, "Keyboard hardware emulates layout", that fixes this issue.

I encourage you to test this feature.