What problem does this solve or what need does it fill?
KeyboardInput currently exposes two ways to identify a key:
logical_key — layout-dependent; winit explicitly warns against using it
for keyboard shortcuts (https://docs.rs/winit/latest/winit/event/struct.KeyEvent.html),
because e.g. with a Russian layout Ctrl+C arrives as Key::Character("с").key_code — the physical key position; using it alone breaks shortcut
conventions on Latin non-QWERTY layouts (AZERTY, Dvorak, ...).
This makes it impossible to implement layout-correct keyboard shortcuts in a
principled way. #24997 was fixed with a local hybrid heuristic in
bevy_ui_widgets::text_input (logical key first, physical fallback for
non-ASCII), but every widget/game that needs shortcuts has to reimplement it.
Spun out of #24997 as requested by @alice-i-cecile.
What solution would you like?
Expose winit's layout-aware key data in bevy_input, e.g. add a
key_without_modifiers: Key field to KeyboardInput, populated from winit's
KeyEventExtModifierSupplement::key_without_modifiers().
This would let shortcut matching use the key's unmodified layout-aware
meaning, which is what native toolkits and browsers do.
What alternative(s) have you considered?
Additional context
key_without_modifiers is behind winit's platform-specific
KeyEventExtModifierSupplement extension and is not available on every
platform (needs investigation for web/mobile), so the field may have to be
optional or best-effort.
What problem does this solve or what need does it fill?
KeyboardInputcurrently exposes two ways to identify a key:logical_key— layout-dependent; winit explicitly warns against using itfor keyboard shortcuts (https://docs.rs/winit/latest/winit/event/struct.KeyEvent.html),
because e.g. with a Russian layout
Ctrl+Carrives asKey::Character("с").key_code— the physical key position; using it alone breaks shortcutconventions on Latin non-QWERTY layouts (AZERTY, Dvorak, ...).
This makes it impossible to implement layout-correct keyboard shortcuts in a
principled way. #24997 was fixed with a local hybrid heuristic in
bevy_ui_widgets::text_input(logical key first, physical fallback fornon-ASCII), but every widget/game that needs shortcuts has to reimplement it.
Spun out of #24997 as requested by @alice-i-cecile.
What solution would you like?
Expose winit's layout-aware key data in
bevy_input, e.g. add akey_without_modifiers: Keyfield toKeyboardInput, populated from winit'sKeyEventExtModifierSupplement::key_without_modifiers().This would let shortcut matching use the key's unmodified layout-aware
meaning, which is what native toolkits and browsers do.
What alternative(s) have you considered?
bevy_inputbuilt on top ofthis data.
Additional context
key_without_modifiersis behind winit's platform-specificKeyEventExtModifierSupplementextension and is not available on everyplatform (needs investigation for web/mobile), so the field may have to be
optional or best-effort.