Wrong key codes for Shift+Number and others - German/Other^^^ keyboard layouts for macOS not supported?

[DerKarlos]

I am using a Mac Air with a German keyboard layout.
Bevy includes winit "0.27.5"

While the number keys 1..9 and 0 are ok,
pressing one of the shift keys puzzles me:
Shift+1 comes as "Key1", not "!"
Shift+2 comes correctly as "Apostrophe"
Shift+3 comes as "Key3", not "§"
Shift+4 comes as "Key4", not "$"
Shift+5 comes as "Key5", not "%"
Shift+6 comes as "Key7" Seven! not "&"
Shift+7 comes correctly as "Slash"
Shift+8 comes as "Key9" ! not "("
Shift+9 comes as "Key0" ! not ")"
Shift+0 comes correctly as "Equal"

Some keys result in odd key-codes also:
The + key comes as "Equals"
The # key comes as "Key3" to

In winit/src/platform_impl/macos/event.rs I see how that could be caused.
'3' | '#' => VirtualKeyCode::Key3,
WINIT does not consider different keyboard layouts (for mac) anyway.
Mostly I can consider this in my code, but not for all, the 3/# for example.

I checked for the scan codes, they look ok. Using them would be a workaround
but I need to consider different keyboard layouts myself!

[madsmtm]

I think this is the desired behaviour when IME is disabled? See Window::set_ime_allowed

[DerKarlos]

Of course. But IME (Text input) is not my topic.
If char_to_keycode is in use, the "desired behaviour" is, to get, what key is just pressed.
This may be used for games etc. to code controls.

In winit, the key detection is done by: "Non-Shift-Char OR Shift-Char"
But the used pairs are not valide for a lot of keys for all other keyboard layouts but English❗️
The doc of char_to_keycode could at last admit this.

Adding code for different keyboard layouts would be an attempt and at last useless
because there is no way to detect the actual active layout by an API.

For internationalisation, scancode_to_keycode needs to be used.
I did a prayer to Murphy: May the scan codes for all keyboard layouts unique!
Sadly, the scan-code values are puzzled and bad to memorise.

wini could offer constants for scan-codes to. Not "row4_key12" but "VirtualKeyCode::Escape".
The english non-shift key characters and functions should be used.
Sure, the mnemonics would only relate to the english layout positions.
But the foreign programmer just has to look up the English layout
and the VirtualKeyCode will always relate to the same key position on thee keyboard.
That's ok for games.

I could offer a merge to wini, adding "scancode_to_keypos" (position) with that table.

[madsmtm]

I haven't really fiddled much with keyboard layouts, so I think I'll direct you to #1806, there has been much work in the past on improving the situation.

[DerKarlos]

Thanks! A lot to read ...

• A lot of # I should have noted before I wrote mine.
• A keyboard input model #753 recommends to remove Scan. I strongly disagree - as long as Key is not layout independent
• I like the: enum with values for functional keys and for Unicode. Or even a struct and only on API, yes.
• We need to agree what we want before we go for the "how". A list of "to solve" examples would be good.
• ...

That #753 discussion looks good. I assume, it will solve my problems.
Also I have doubts if this is possible at all. Do we need to know the active keyboard layout? Can we know?
"Please look away Murphy"

[maroider]

This is something I think you won't have an issue with once the keyboard rework lands (see https://github.com/rust-windowing/winit/tree/new-keyboard-v3 for the most up-to-date state of that).