Keys on an alternative layout

[rkimoakbioinformatics]

Thanks for this nice crate. I use an alternative keyboard layout on macOS. It seems that use_hotkeys! detects physical keys. Is there a way to detect a key on the alternative layout?

[friendlymatthew]

TLDR: No, we use code(). This is a selfish design choice, so we'll need to change this. Feel free to attack this issue!

Local development workaround: Use the debug feature flag to see the code of a given key press in your browser console. Use that as it's key id when you write your macros.

Yeah I've been thinking about this dilemma. I originally used key() as the key identifier, but I ran into issues.

This lead to a fork in design and I chose code() as the key identifier.

The MDN docs seem to point out why using code() might be a bad choice:

This property is useful when you want to handle keys based on their physical positions on the input device rather than the characters associated with those keys. Be aware, however, that you can't use the value reported by KeyboardEvent.code to determine the character generated by the keystroke, because the keycode's name may not match the actual character that's printed on the key or that's generated by the computer when the key is pressed.

For example, the code returned is "KeyQ" for the Q key on a QWERTY layout keyboard, but the same code value also represents the ' key on Dvorak keyboards and the A key on AZERTY keyboards. That makes it impossible to use the value of code to determine what the name of the key is to users if they're not using an anticipated keyboard layout.

So I guess this means anyone who isn't using QWERTY is SOL? This is pretty bad.

To determine what character corresponds with the key event, use the KeyboardEvent.key property instead.

We should revert back to key(). And handle this edge case.

Let me know if you want to work on this issue @rkimoakbioinformatics!

ccing: @JustBobinAround @zakstucke @maxbergmark on their thoughts

[rkimoakbioinformatics]

Thanks for the explanation. I have created a PR to solve both alternative keyboard layouts and the space bar. Would this work?

[rkimoakbioinformatics]

127

[maxbergmark]

Hey @rkimoakbioinformatics! I'm a bit late to the party, but from some local testing it seems that this has been a bit of a breaking change. From the links you posted above, the code() returns e.g. "KeyA", while key() returns "a". This isn't a major problem, but it will of course break any existing implementation that are using alphanumeric hotkeys (digits are changed from e.g. "Digit1" to "1"). This change needs to be documented, and probably needs a new version to avoid breaking existing projects.

[rkimoakbioinformatics]

Oh indeed. Sorry about that. I can think of two possible solutions:

• Documenting this as a breaking change.
• Convert "keya" to "a", "digit1" to "1", etc. when parsing user hotkey combinations. I guess this parsing happens only once and if so, performance hit by this may be negligible?

[friendlymatthew]

Thanks for flagging this @maxbergmark! This is a breaking change. However, I don't want to release v.0.3 just yet. There's definitely some work and refactoring that I would like to do before upgrading.

Instead, I propose we pack all of this work into a feature flag use_key. This means the crate will defer to using code() unless it's explicitly stated otherwise.

^ This should be pretty simple work. I'll create another issue for this task.

[rkimoakbioinformatics]

That sounds great. Thanks.