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
DeviceEventfrom #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.