-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Add set_cursor_position method to Window #917
Conversation
crates/bevy_winit/src/lib.rs
Outdated
window.set_cursor_grab(locked).unwrap(); | ||
window | ||
.set_cursor_grab(locked) | ||
.expect("Unable to un/grab cursor"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that we have logging set up by default, I think it makes sense to make these types of errors "soft errors" (ex: just use error!("Unable to un-grab cursor")
).
I'd much prefer using "recoverable errors" when possible, but in this case the "command" has already been sent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you suggest changing this error handling?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure you can call these recoverable. If the game expects the cursor grabbed, it most probably won't work as expected with cursor ungrabbed.
Similarly game expects cursor to be at the set position and behavior when it is not may be unpredictable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Potentially there could be a mechanic to set a WindowCommand
to panic on failure (rather than print an error), so then it could be defined whether exclusive cursor grab (or other window commands) can fail gracefully in the context of the configuring application.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I'm sure some people would find that useful, adding a bunch of "knobs" like that have negative implications too:
- more implementation complexity
- more code paths. this makes the behavior harder to document, support, and understand
I think in this case we should just make a decision. It won't please everyone, but it will probably please 99.9% of people.
And if we're going to choose one, I think we should log it as a "soft" error. This is the sort of thing that will probably fail for "os support reasons". I don't think devs will want their games to crash because the cursor didn't lock. If someone must have WindowCommands panic in this case, they can register a new tracing
subscriber that panics on incoming logs. Or (probably even better) we could create a new Events<WindowError>
collection, which developers could consume to detect these cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If that's the way you would like to go then I support it. I especially support the soft errors, and the events would be a good way of doing it.
OK. I added |
I can do that if you want, as a different pr |
This allows programatically setting cursor position in Window.