Winit 0.30.6 triggers two key press events instead of one #4048
Comments
|
Can confirm this is a winit bug, traced back to 107bf91. |
|
Though looking at the commit, maybe this means egui needs to handle things differently? |
|
This broke bevy_egui integration too. It retrieves events from bevy, which exposes partially processed events and some winit event data. https://github.com/vladbat00/bevy_egui/blob/main/src/systems.rs |
The filtered events were still processed even though they shouldn't once we know that they're filtered. Fixes rust-windowing#4048.
|
See: emilk/egui#5509 Works in winit 0.30.5, fails in 0.30.6. Repro available. |
The filtered events were still processed even though they shouldn't once we know that they're filtered. Fixes #4048.
The filtered events were still processed even though they shouldn't once we know that they're filtered. Fixes rust-windowing#4048.
|
Nice. When will this reach crates.io? Thanks. Edit: just discovered that the unreleased version on trunk has breaking changes, so the version from Github is not a direct replacement. So there is no quick fix for this. |
The filtered events were still processed even though they shouldn't once we know that they're filtered. Fixes #4048.
|
winit 0.30.7 resolves the issue! Thank you all! |
|
Indeed it does. My 3D world viewer is running nicely now. Thanks, and have a good holiday! |
Description
Problem found while using popular egui library with winit 0.30.6. winit 0.30.5 works correctly.
Text edit field registers two key press events instead of one.
If you believe that it is fault of egui integration and the new behavior is correct, feel free to close this issue. Wanted to report it just in case!
OS and window mananger
Ubuntu 24.04.1 LTS
i3 4.24
Winit version
0.30.6
The text was updated successfully, but these errors were encountered: