Fix unwanted eye (camera) movement when using shortcuts #8975
Conversation
There was a problem hiding this comment.
Hi! Thanks for opening this pull request.
Because this is your first time contributing to this repository, make sure you've read our Contributor Guide and Code of Conduct.
| let modifiers_pressed = egui_ctx.input(|input| input.modifiers.any()); | ||
| if modifiers_pressed { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
Currently we speed up and slow down the WSAD movement when the user presses shift/ctrl, and it seems like this code would break that?
More likely we want to only return early if any modifiers other than shift/ctrl are pressed.
There was a problem hiding this comment.
Thanks @emilk for the feedback. I wasn't aware of this behavior.
In this case, I'm proposing an alternative solution, please see my latest change: https://github.com/rerun-io/rerun/pull/8975/files#diff-daa0aae659935f597d1eb9ce8af241e875d7e61e03cf725151ec26f0c75efd30R462-R463
There was a problem hiding this comment.
This approach mainly to stop the shortcut to propagate by clearing the input keys.
@emilk How do you feel about implementing an event propagation control feature for egui? Would this be something against the design of egui?
|
@kailiuca are you planning to follow-up on this or do you want someone else to take over? |
e1533e8 to
9a0db2c
Compare
9a0db2c to
17b7923
Compare
|
Didn't notice this was ready for review again. |
…opagating to other UI components
17b7923 to
4e7b6c2
Compare
What
This PR addressed a UI glitch that eye could move slightly upon firing up a shortcut, e.g., ctrl + s. As shown in the video below, across all the platforms, due to the view still listening for any keyboard_navigation, there is a small backwards (due to "S" presence") move before (at 0:03 in the video below) and after (0:05) the save dialog.
slight_movement.mp4
Besides, there is also a platform-dependent issue: when testing in Ubuntu 22.04.5 LTS, after closed the save dialog, the egui input context still registered the ctrl modifier and "S" keys_pressed, causing the eye moved backwards as long as cursor hovers the view (0:14 and 0:19 in the video below). I've tested with Windows 11 and web-version, it worked without such issue.
continuous_movement.mp4
The fix
To address the issue, a shortcut key clearing from input has been implemented (https://github.com/rerun-io/rerun/pull/8975/files#diff-daa0aae659935f597d1eb9ce8af241e875d7e61e03cf725151ec26f0c75efd30R462-R463) to stop the shortcut to propagate. But maybe an event propagation control could be implemented on egui? @emilk love to hear your thoughts.
To address the issue no. 1 above, checked formodifiers_pressedis added so eye movement won't be activated if any of the modifier key pressed (https://github.com/rerun-io/rerun/pull/8975/files#diff-242e5fb1310bf1a865d6c25402303099d00d6a81e76137ccfaaf36db8987b24bR448-R453). I find this should be a clean approach, do let me know if there is any such case that the eye movement should be carried out with a modifier key @emilk.To address the issue no. 2, I'm thinking to clear all modifier and key input from the egui context, before triggering the UICommands (https://github.com/rerun-io/rerun/pull/8975/files#diff-46de70906d858ca551e573c4bc0e2f1d5415e792d3b91d6e7653ec3d44b78527R705-R710). One part I'm not so sure about the current implementation is how the keyboard input is cleared. But I find it make sense to clear them before the UICommands as proposed in this fix. Let me know if there is more clever way for this issue, or any concerns about my fix.