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.
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.
How do you suggest changing this error handling?
There was a problem hiding this comment.
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.
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.
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.
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.
Moxinilian
added
C-Feature
|
OK. I added |
|
I can do that if you want, as a different pr |
This allows programatically setting cursor position in Window.