Revert most of #16222 and add gamepad accessors#16425
Merged
Conversation
rparrett
reviewed
Nov 18, 2024
alice-i-cecile
approved these changes
Nov 18, 2024
Member
alice-i-cecile
left a comment
There was a problem hiding this comment.
I like the end user UX much better here. I'm glad to see accessors exposed for analog / digital, and you can still construct a Gamepad externally and it's fully reflect still so I think this should satisfy the needs of power users and input mocking.
Shatur
suggested changes
Nov 18, 2024
Contributor
Shatur
left a comment
There was a problem hiding this comment.
Agree, I like this approach more!
Maybe keep some of the doc changes from my PR? See the suggested changes.
Also a few methods could be delegated. I noticed it back then, but didn't fix since they were removed.
Co-authored-by: Hennadii Chernyshchyk <genaloner@gmail.com> Co-authored-by: Rob Parrett <robparrett@gmail.com>
Shatur
approved these changes
Nov 18, 2024
mockersf
pushed a commit
that referenced
this pull request
Nov 19, 2024
# Objective #16222 regressed the user experience of actually using gamepads: ```rust // Before 16222 gamepad.just_pressed(GamepadButton::South) // After 16222 gamepad.digital.just_pressed(GamepadButton::South) // Before 16222 gamepad.get(GamepadButton::RightTrigger2) // After 16222 gamepad.analog.get(GamepadButton::RighTrigger2) ``` Users shouldn't need to think about "digital vs analog" when checking if a button is pressed. This abstraction was intentional and I strongly believe it is in our users' best interest. Buttons and Axes are _both_ digital and analog, and this is largely an implementation detail. I don't think reverting this will be controversial. ## Solution - Revert most of #16222 - Add the `Into<T>` from #16222 to the internals - Expose read/write `digital` and `analog` accessors on gamepad, in the interest of enabling the mocking scenarios covered in #16222 (and allowing the minority of users that care about the "digital" vs "analog" distinction in this context to make that distinction) --------- Co-authored-by: Hennadii Chernyshchyk <genaloner@gmail.com> Co-authored-by: Rob Parrett <robparrett@gmail.com>
ecoskey
pushed a commit
to ecoskey/bevy
that referenced
this pull request
Dec 2, 2024
…#16425) # Objective bevyengine#16222 regressed the user experience of actually using gamepads: ```rust // Before 16222 gamepad.just_pressed(GamepadButton::South) // After 16222 gamepad.digital.just_pressed(GamepadButton::South) // Before 16222 gamepad.get(GamepadButton::RightTrigger2) // After 16222 gamepad.analog.get(GamepadButton::RighTrigger2) ``` Users shouldn't need to think about "digital vs analog" when checking if a button is pressed. This abstraction was intentional and I strongly believe it is in our users' best interest. Buttons and Axes are _both_ digital and analog, and this is largely an implementation detail. I don't think reverting this will be controversial. ## Solution - Revert most of bevyengine#16222 - Add the `Into<T>` from bevyengine#16222 to the internals - Expose read/write `digital` and `analog` accessors on gamepad, in the interest of enabling the mocking scenarios covered in bevyengine#16222 (and allowing the minority of users that care about the "digital" vs "analog" distinction in this context to make that distinction) --------- Co-authored-by: Hennadii Chernyshchyk <genaloner@gmail.com> Co-authored-by: Rob Parrett <robparrett@gmail.com>
ecoskey
pushed a commit
to ecoskey/bevy
that referenced
this pull request
Jan 6, 2025
…#16425) # Objective bevyengine#16222 regressed the user experience of actually using gamepads: ```rust // Before 16222 gamepad.just_pressed(GamepadButton::South) // After 16222 gamepad.digital.just_pressed(GamepadButton::South) // Before 16222 gamepad.get(GamepadButton::RightTrigger2) // After 16222 gamepad.analog.get(GamepadButton::RighTrigger2) ``` Users shouldn't need to think about "digital vs analog" when checking if a button is pressed. This abstraction was intentional and I strongly believe it is in our users' best interest. Buttons and Axes are _both_ digital and analog, and this is largely an implementation detail. I don't think reverting this will be controversial. ## Solution - Revert most of bevyengine#16222 - Add the `Into<T>` from bevyengine#16222 to the internals - Expose read/write `digital` and `analog` accessors on gamepad, in the interest of enabling the mocking scenarios covered in bevyengine#16222 (and allowing the minority of users that care about the "digital" vs "analog" distinction in this context to make that distinction) --------- Co-authored-by: Hennadii Chernyshchyk <genaloner@gmail.com> Co-authored-by: Rob Parrett <robparrett@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Objective
#16222 regressed the user experience of actually using gamepads:
Users shouldn't need to think about "digital vs analog" when checking if a button is pressed. This abstraction was intentional and I strongly believe it is in our users' best interest. Buttons and Axes are both digital and analog, and this is largely an implementation detail. I don't think reverting this will be controversial.
Solution
Into<T>from Gamepad improvements #16222 to the internalsdigitalandanalogaccessors on gamepad, in the interest of enabling the mocking scenarios covered in Gamepad improvements #16222 (and allowing the minority of users that care about the "digital" vs "analog" distinction in this context to make that distinction)