Handle winit's WindowEvent::ModifiersChanged
#13357
Conversation
|
Welcome, new contributor! Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨ |
matthunz
changed the title
WindowEvent::ModifiersChanged
alice-i-cecile
added
C-Bug
crates/bevy_winit/src/lib.rs
Outdated
| // Send a `KeyboardInput` event if this key is not a modifier. | ||
| let keyboard_event = converters::convert_keyboard_input(event, window); | ||
| let mod_keys = [Key::Alt, Key::Control, Key::Shift, Key::Super]; | ||
| if !mod_keys.contains(&keyboard_event.logical_key) { |
There was a problem hiding this comment.
Why do we need to make this re-sending conditional? Don't we want to retain the old behavior on all other platforms (which don't send ModifiersChanged)?
There was a problem hiding this comment.
Huh sorry I didn't realize ModifiersChanged isn't triggered on other platforms. Windows looks to be working again in
c25df8f
There was a problem hiding this comment.
Also I left the conditional re-sending on MacOS to avoid duplicating events - WindowEvent::KeyboardInput and ModifiersChanged seem to be triggered at the same time except with the native overlay scenario
|
this feels like it should be fixed in Winit rather than in Bevy in the issue you mention this works correctly with winit example, so I would prefer more investigation done before doing that many platform-specific things there |
I totally agree 👍 (unless winit does have a reason) What I saw in that example is winit does provide the input events, just in this alternative way. It feels weird for them to provide a |
|
I got some more information from Not 100% sure I understand but it does sound like we'd still want to handle |
Objective
KeyboardInputevents not being triggered by MacOS native overlays #13356Solution
WindowEvent::KeyboardInputtoModifiersChanged. Currently these are the only events triggered when MacOS native overlays interrupt the app.Testing
Works for me on MacOS sonoma 😄 no breaking changes that I can see