Add conversions from/to XKB codes#98
Conversation
| /// Get the [`NamedKey`] for a an XKB keysym. | ||
| pub fn from_xkb_keysym(keysym: u32) -> Option<Key> { | ||
| match keysym { | ||
| 0x20 => Some(Key::Character(" ".into())), |
There was a problem hiding this comment.
Winit uses the xkbcommon_dl crate here for predefined keysym aliases. Technically it would have been easier to do the same, but I did not want to rely on any dependencies.
This does however make this code a little less maintainable, since you'll essentially have to trust that I picked all the correct values (or that my machine-conversion with vim macros did the right thing). Considering the same applies to keycodes, I think this should be fine, but I can see it both ways.
8f97049 to
98368c3
Compare
98368c3 to
03b47d3
Compare
The `keyboard-types` crate is useful for having a standardized target for various shared keyboard functionality, however most applications will receive keys in the system's format. This patch adds a translation layer from system XKB key codes to `keyboard-types`, allowing applications to easily convert between the two without having to rely on copy/pasting the same conversion logic between several projects. Currently the conversion to XKB codes is only available for keycodes, not keysyms, since the latter does not have a unique conversion. See rust-windowing#97.
|
I should probably mention that the |
|
Any feedback would be appreciated, been a while now. |
The
keyboard-typescrate is useful for having a standardized target for various shared keyboard functionality, however most applications will receive keys in the system's format.This patch adds a translation layer from system XKB key codes to
keyboard-types, allowing applications to easily convert between the two without having to rely on copy/pasting the same conversion logic between several projects.Currently the conversion to XKB codes is only available for keycodes, not keysyms, since the latter does not have a unique conversion.
See #97.
Only doing XKB here since I don't have access to the other platforms, however I believe that this on its own is already of value and it does not significantly harm any of the other platforms (especially once LTO tosses all this code out during compile).
I've gone with an approach that pulls zero additional dependencies, allowing these functions to always be available without feature flags.