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
Implement proper grabbing behavior on macOS #1093
Comments
Can anyone merge this PR? This feature is critical for developing cross-platform video games. If we cannot set mouse grab on macOS, then camera movement will become quite weird there. |
@panda2134 this is not a PR, it's an issue. macOS has locking, but not confining. |
Sorry for mistaking this as a PR. If it's the OS's fault, then that's acceptable limitation. Also I just found out that it works when locking is used after setting the cursor to somewhere in the window. |
Yes, the cursor should be in the window to lock it. that's how it works on most OSes. |
You can simulate proper cursor grabbing with the cursor lock API, by only locking after the user first clicks in the window. (I believe this is required for Web anyway, because you can only grab the cursor in response to user interaction?) |
Mouse grabbing does not work correctly on MacOS: the mouse is locked to the initial position instead of being confined to the primary window. Relates to DigitalExtinction#354. Relates to rust-windowing/winit#1093.
Mouse grabbing does not work correctly on MacOS: the mouse is locked to the initial position instead of being confined to the primary window. Relates to DigitalExtinction#354. Relates to rust-windowing/winit#1093.
Right now on macOS, the cursor just gets locked to its current location, instead of getting locked to the area of the window. A proper solution that locks the cursor to the window exists and is documented, but hasn't been implemented yet.
See this comment:
winit/src/platform_impl/macos/window.rs
Lines 519 to 523 in 2442305
The text was updated successfully, but these errors were encountered: