-
Notifications
You must be signed in to change notification settings - Fork 946
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
scan_code and virtual_key_code are swapped #2092
Comments
@madsmtm I would like to contribute to |
I've no idea, the keyboard model is not something I've looked at at all. See this meta issue: #1806, the fix may be present somewhere in those PRs already. Though if the fix is as simple as it sounds, your could try making a PR to fix it, though a big issue right now is that we don't have a WASM maintainer to approve it at the moment (see Testers and Contributors table), so not sure that would get you anywhere either. |
The only sane keyboard input API on the web is fundamentally incompatible with winit's current keyboard API. I unfortunately cannot give you an ETA on when #1888 (and thus a reasonable way of doing what you want to do) will get merged into the |
@maroider What about an imperfect but less broken WASM implementation? I could do the following:
I know this is not a bullet-proof solution but the current implementation is broken in a way which prevents projects like Nannou from delivering a first-class WASM experience. The biggest impediment probably is the modifiers state not being handled correctly. As I said: I would invest some time to help making the implementation less broken. |
Fixed on master. |
https://github.com/rust-windowing/winit/blob/master/src/platform_impl/web/web_sys/event.rs considers
event.key_code()
/event.char_code()
to be thescan_code
of theKeyboardInput
event andevent.code()
to be thevirtual_key_code
of theKeyboardInput
event while it should be the other way around.How to verify yourself: Use the links given below and a German keyboard layout and press the German
z
keyevent.key_code()
/event.char_code()
will return 122 (the ASCII ofz
) i.e. the virtual meaning of the keyevent.code()
will returnKeyY
i.e. the physical key locationDemonstration of workaround in my personal project: Woyten/tune@38b7ecd and Woyten/tune@fcec2d3
The text was updated successfully, but these errors were encountered: