Distinction between MouseMotion and CursorMoved events is unclear in docs #5083
Assignees
Comments
alice-i-cecile
added
C-Docs
|
It's also not clear why one refers to "mouse" and the other refers to "cursor". Perhaps there's a significance to this upstream in |
|
And of course, |
|
My understanding is that mouse motion is about the physical motion of the actual mouse - this ignores pointer acceleration for example. Cursor movement is about the movement of the cursor, i.e. the thing that you use to click with. |
alice-i-cecile
removed
the
C-Usability
alice-i-cecile
changed the title
inodentry
pushed a commit
to IyesGames/bevy
that referenced
this issue
Aug 8, 2022
# Objective - Fixes bevyengine#5083 ## Solution I looked at the implementation of those events. I noticed that they both are adaptations of `winit`'s `DeviceEvent`/`WindowEvent` enum variants. Therefore I based the description of the items on the documentation provided by the upstream crate. I also added a link to `CursorMoved`, just like `MouseMotion` already has. ## Observations - Looking at the implementation of `MouseMotion`, I noticed the `DeviceId` field of the `winit` event is discarded by `bevy_input`. This means that in the case a machine has multiple pointing devices, it is impossible to distinguish to which one the event is referring to. **EDIT:** just tested, `MouseMotion` events are emitted for movement of both mice.
james7132
pushed a commit
to james7132/bevy
that referenced
this issue
Oct 28, 2022
# Objective - Fixes bevyengine#5083 ## Solution I looked at the implementation of those events. I noticed that they both are adaptations of `winit`'s `DeviceEvent`/`WindowEvent` enum variants. Therefore I based the description of the items on the documentation provided by the upstream crate. I also added a link to `CursorMoved`, just like `MouseMotion` already has. ## Observations - Looking at the implementation of `MouseMotion`, I noticed the `DeviceId` field of the `winit` event is discarded by `bevy_input`. This means that in the case a machine has multiple pointing devices, it is impossible to distinguish to which one the event is referring to. **EDIT:** just tested, `MouseMotion` events are emitted for movement of both mice.
ItsDoot
pushed a commit
to ItsDoot/bevy
that referenced
this issue
Feb 1, 2023
# Objective - Fixes bevyengine#5083 ## Solution I looked at the implementation of those events. I noticed that they both are adaptations of `winit`'s `DeviceEvent`/`WindowEvent` enum variants. Therefore I based the description of the items on the documentation provided by the upstream crate. I also added a link to `CursorMoved`, just like `MouseMotion` already has. ## Observations - Looking at the implementation of `MouseMotion`, I noticed the `DeviceId` field of the `winit` event is discarded by `bevy_input`. This means that in the case a machine has multiple pointing devices, it is impossible to distinguish to which one the event is referring to. **EDIT:** just tested, `MouseMotion` events are emitted for movement of both mice.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What problem does this solve or what need does it fill?
As shown in the mouse_input_events example, Bevy exposes both a
MouseMotionandCursorMovedevent type.These are poorly documented, but it appears that
MouseMotionis relative, whileCursorPositionis absolute (and tied to a specific window).What solution would you like?
Clearly differentiate these types in the docs and explain why they both exist (and when you should use one vs the other).
What alternative(s) have you considered?
Remove
MouseMotion, and only exposeCursorMoved. However, it's not clear ifMouseMotioncan always be reconstructed; I'm particularly nervous about what happens when the cursor is locked to the screen.Additional context
Related to #5034, which also tries to simplify the UX here.
The text was updated successfully, but these errors were encountered: