Add ScanCode enum.

[linkpy]

What problem does this solve or what need does it fill?

For better keyboard layout support. KeyCode depends on the user's keyboard layout while scancodes doesn't (KeyCode::A wouldn't be the same physical key on a QWERTY or an AZERTY keyboard, while ScanCode::A would be the A key on a QWERTY, while it would be the Q key on an AZERTY). Scancodes are already supported in events, but not with Input<T>.

Describe the solution would you like?

Add a ScanCode enum. A good list to begin with would be SDL's ScanCode. If i remember correctly, SDL_Scancode enumeration is based on the USB standard specification.

Describe the alternative(s) you've considered?

An alternative would be to implement that in every project, but I think that kind of things would be better if directly inside of the engine.

Additional context

None

[chayleaf]

Scan codes are important, but text input is more than just key codes, IME support needs to be added as well. AFAIK currently no windowing solution (winit, SDL, GLFW) handles IMEs perfectly.

In order for IMEs to work in fullscreen application (and work well in non-fullscreen applications), the app has to render the IME window itself by querying the system for current IME state. IMEs also work differently for Chinese, Japanese and Korean. On Windows it can be done with something like https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/IME

There's more important info here https://www.gamasutra.com/blogs/StoyanNikolov/20130927/201151/Game_i18n_via_IME.php

On Android the common approach is to send the user into a fullscreen native textbox upon tapping the in-game textbox. On the web there's no IME API currently available or planned, but the browser isn't fullscreen - perhaps it would be possible to make the user focus on an invisible HTML textbox?

[chayleaf]

@linkpy maybe a better title would be something like "separate text input and game input"?

[cdaringe]

i think the intent is to add the capability to map input to physical keys vs virtual keys (KeyCode). i don't think window/UI text input is even part of this topic.

i'm a colemak user, but want WASD key mappings form motion, which on my keyboard is WARS. using KeyCode enum doesn't work for me. some games & engines handle this well. others, I must change keyboard layouts before game launch.

[linkpy]

At no moment i mentioned text or IME input. It's exactly what @cdaringe said.
It's to have a layout-independent way to define keys.

[amadeusine]

I believe some form of scancodes is an important addition that many users can benefit from.
Would specific keyboard layouts/profiles be considered as custom definitions by Bevy users or within Bevy itself? I'm wondering whether there would have to be a minimum number of layout presets given that KeyCode would be used for mapping of virtual keys, if I understand this correctly.

[linkpy]

There is no need to have layouts and all, everything is handled by the OS and SDL. The ScanCode is the key index pressed, the KeyCode is the translated key by the OS's keyboard manager.

[mattdm]

Another consideration: on my system (Fedora Linux 34 prerelease running GNOME with mostly the default keyboard layout), some keys don't have keycodes for ... some reason. These include Right Alt (scancode: 100, keycode: None) and Enter on the numeric keypad (scancode: 95, keycode: None).

(GNOME sets Right Alt to AltGr by default. No idea what's up with the keypad enter though.)

[maroider]

There has been a lot of discussion about this specific issue, among other things, in rust-windowing/winit#753. There's also a meta-issue for keyboard input: rust-windowing/winit#1806.

Ultimately, it was decided that Winit will use enumeration names from the uievents-key and uievents-code specifications, with a couple of exceptions/additions, and I'd expect Bevy to benefit from adopting something similar. I think there may be something to be gained from having multiple projects converging around a single abstraction for this (like keyboard-types), but Winit is currently rolling its own enumerations and structs.

[targrub]

@linkpy Should this issue now be considered Closed?

[james7132]

This was added in #5495. Closing.

[alice-i-cecile]

It's not an enum there: reopening :)

[maniwani]

If/when rust-windowing/winit#2662 is merged upstream, there will be enums for both the physical location of a key and the semantic meaning of a keypress.