Enable applications to report whether they handled an input event #31
Comments
rib
added a commit
that referenced
this issue
Sep 19, 2022
The callback given to `AndroidApp::input_events()` is now expected to return `InputStatus::Handled` or `InputStatus::Unhandled`. When running with NativeActivity then if we know an input event hasn't been handled we can notify the InputQueue which may result in fallback handling. Although the status is currently ignored with the GameActivity backend. Fixes: #31
rib
added a commit
that referenced
this issue
Sep 19, 2022
The callback given to `AndroidApp::input_events()` is now expected to return `InputStatus::Handled` or `InputStatus::Unhandled`. When running with NativeActivity then if we know an input event hasn't been handled we can notify the InputQueue which may result in fallback handling. Although the status is currently ignored with the GameActivity backend. Since this is a breaking change that also affects the current Winit backend this updates the winit based examples to stick with the 0.3 release of android-activity for now. Fixes: #31
rib
added a commit
that referenced
this issue
Sep 19, 2022
The callback given to `AndroidApp::input_events()` is now expected to return `InputStatus::Handled` or `InputStatus::Unhandled`. When running with NativeActivity then if we know an input event hasn't been handled we can notify the InputQueue which may result in fallback handling. Although the status is currently ignored with the GameActivity backend. Since this is a breaking change that also affects the current Winit backend this updates the winit based examples to stick with the 0.3 release of android-activity for now. Fixes: #31
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When running with
NativeActivity/InputQueuethen when we "finish" the processing of an event we can tell the input queue if the application handled the event and if not it's possible that there will be some fallback / default handling.Currently we're reporting that the event was always handled so there will never be any fallback, since this was a simple way to have consistency with
GameActivity.We should make it possible to support fall backs via an
InputQueueor potentially support fall backs withGameActivityin the future too.This was highlighted during the review for this winit backend PR: rust-windowing/winit#2444 where it was also noted that winit may want expose the same notion to allow fall backs for volume controls.
The text was updated successfully, but these errors were encountered: