Skip to content
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

CursorState::Grab does not report mouse delta on macOS #165

Closed
mystal opened this issue Apr 27, 2017 · 4 comments
Closed

CursorState::Grab does not report mouse delta on macOS #165

mystal opened this issue Apr 27, 2017 · 4 comments
Labels
D - average Likely as difficult as most tasks here DS - macos H - help wanted Someone please save us P - normal Great to have S - platform parity Unintended platform differences

Comments

@mystal
Copy link
Contributor

mystal commented Apr 27, 2017

You still get MouseMoved events with the absolute position of the mouse, but it does not change. As a result, it's kind of useless. According to macOS documentation, you should instead check for deltaX and deltaY on the NSEvent.

As far as I can tell, winit doesn't currently report the mouse cursor delta in any events. I think it makes sense to add the mouse delta to the MouseMoved event. Any thoughts?

@Ralith
Copy link
Contributor

Ralith commented May 10, 2017

#164 introduced API for raw input events, which is more appropriate for things like first-person camera control. Would it make more sense to extend the macos backend with support generating such events? It seems to me that you generally want either high-resolution unfiltered relative mouse movement data or filtered window-space pointer positions, not filtered window-space relative pointer movement, and not both at once.

@LPGhatguy
Copy link
Contributor

@Ralith Will we need a new DeviceEvent variant for mouse movement based on the API you introduced? I see that it exposes an axis and an f64 value, which might not be suitable for platforms like Windows where raw input is reported as one event from the OS

@Ralith
Copy link
Contributor

Ralith commented May 22, 2017

As discussed on IRC, the intention of DeviceEvent is explicitly that multiple events be generated if a host even contains motion on multiple axes. For example, an X11 device event may represent motion on arbitrarily many axes at once, but instead of introducing a dynamically allocated vector, we just generate N separate motion events.

edit for posterity: @LPGhatguy has convinced me that it's worth having input device class specific event types for the sake of API usability.

@francesca64 francesca64 added H - help wanted Someone please save us DS - macos D - average Likely as difficult as most tasks here P - normal Great to have S - platform parity Unintended platform differences labels May 6, 2018
@swiftcoder
Copy link
Contributor

This is complete, right? DeviceEvent::MouseMotion has existed for some time now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
D - average Likely as difficult as most tasks here DS - macos H - help wanted Someone please save us P - normal Great to have S - platform parity Unintended platform differences
Development

No branches or pull requests

7 participants