Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use the keyboard_types crate in winit #2394

Open
amrbashir opened this issue Jul 25, 2022 · 4 comments
Open

Use the keyboard_types crate in winit #2394

amrbashir opened this issue Jul 25, 2022 · 4 comments
Labels
C - needs discussion Direction must be ironed out S - api Design and usability S - maintenance Repaying technical debt

Comments

@amrbashir
Copy link
Contributor

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

@madsmtm madsmtm added S - api Design and usability C - needs discussion Direction must be ironed out S - maintenance Repaying technical debt labels Jul 26, 2022
@madsmtm
Copy link
Member

madsmtm commented Jul 26, 2022

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

@madsmtm
Copy link
Member

madsmtm commented Jan 31, 2023

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

@madsmtm madsmtm added this to the Version 0.31.0 milestone Jun 24, 2024
@madsmtm
Copy link
Member

madsmtm commented Jun 28, 2024

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C - needs discussion Direction must be ironed out S - api Design and usability S - maintenance Repaying technical debt
Development

No branches or pull requests

3 participants