Use the keyboard_types crate in winit

[amrbashir]

Using the keyboard_types crate as a standardized keyboard crate among the ecosystem. see tauri-apps/tao#460

[madsmtm]

Good idea! Will probably have to wait until we get the new keyboard API stuff worked out though: #1806

[madsmtm]

I've opened pyfisch/keyboard-types#19 for tracking this in keyboard-types

[madsmtm]

This is also desired by Xilem / Masonry.

@kchibisov also noted that he needs more keyboard functionality in Alacritty than keyboard-types provide, might need some way to query the keyboard layout? In any case, might make sense to iterate more on the API before we commit to this.

[nicoburns]

This would also be helpful for us in https://github.com/DioxusLabs/blitz. Our use case is to be able to make crates that implement keyboard shortcuts (and thus need to be able to respond to key events) without depending on winit (and bringing in all the actual platform integration code). Some kind of winit_types or winit_keyboard_types crates that separately exports winit's existing types would also work for this use case, although an ecosystem-wide "vocabulary crate" would still be ideal.

[Exotik850]

The need to expose keyboard_types data from winit remains an important issue for the ecosystem. Implementing this through either a feature flag or a separate winit_keyboard_types crate (as discussed previously) would significantly reduce the current pain points many developers face. Right now, crates that need to work with winit's keyboard events are forced to either duplicate type definitions or write potentially error-prone conversion code. By making these types more accessible, we could reduce code duplication across projects and make it much simpler for crates to properly handle keyboard input without requiring the full winit dependency. This would be especially valuable for libraries that only need to process keyboard data before window management functionality. Based on previous discussions, both the feature flag and separate crate approaches seem viable - I'm curious which path the maintainers think would better serve the community's needs.