-
Notifications
You must be signed in to change notification settings - Fork 920
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mouse device events #192
Mouse device events #192
Conversation
Note that I don't go to any special effort in the X11 backend to ensure that the raw input data presented as mouse events are in fact relative pointing device motion, because I haven't been able to identify any cases where any other type of data can possibly arrive on the conventional axes. |
Since Wayland is likely to require winit's involvement to get controller input, part of the motivation of this PR--that the set of device classes whose input must pass through winit is small--no longer seems to hold. There will always be generic events, not just as a fallback but as a routine part of the API. That said, there's still a usability case for special-casing mouse motion. |
This makes the API more intuitive for common use-cases and allows us to better propagate platform knowledge of motion semantics.
I think we should rename Other than that, LGTM; I'm willing to do the Windows implementation and have it written against an old version of winit right now. |
da49125
to
c475fc6
Compare
This emphasizes the difference between motion of the host GUI cursor, as used for clicking on things, and raw mouse(-like) input data, as used for first-person controls.
c475fc6
to
15121d3
Compare
What's the state of this, relating to the notion of device events that is currently in winit? |
@Ralith I really like this PR, so I think I'm going to add support for the missing platforms to this, fix up the OSX build, fix the conflicts then open a PR with these commits. Alternatively I can also open a PR against your fork if you'd prefer to just merge my commits into this PR. |
Feel free to make a new PR if you like; saves on coordination overhead, and I think you have stronger motivation to see changes along these lines merged than I presently do. |
Closing in favor of #344. |
This makes the API more intuitive for common use-cases and allows us to better propagate platform knowledge of motion semantics.
My original design for
DeviceEvent
from #164 attempted to be very abstract in the interest of supporting the broadest possible range of input device types, at the cost of being somewhat less obvious. Thanks in large part to discussion with @LPGhatguy, I now believe this was unnecessary. In particular, I believe that the set of input device types supported by major platforms' windowing APIs is very small, and hence merits richer, more semantic event types to improve winit's ease-of-use.Generic events are retained to ensure we never need to discard data, but I think we should in general try to add handling for every device type we encounter in practice. On the flip side, I think we should be careful to keep the scope of input devices handled as narrow as possible, exposing only events that cannot reasonably be accessed without winit's cooperation.
Do these changes make sense to people?
I also took the opportunity to normalize event naming slightly.