Desktop: Support input from drawing tablets - #4354
Conversation
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 40 files
Confidence score: 5/5
- Safe to merge after the addressed issues were fixed.
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
|
!build desktop (Run ID 29704545193) |
|
|
|
|
PoC with future PRs using the input attributes that are passed through. 2026-07-19.23-46-46.mp4 |
0HyperCube
left a comment
0HyperCube
left a comment
There was a problem hiding this comment.
Looks good; mostly just renaming some things.
| window_fullscreen: bool, | ||
| window_pending_drag: bool, | ||
| pointer_position: PhysicalPosition<f64>, | ||
| pointer_lock_position: Option<PhysicalPosition<f64>>, |
There was a problem hiding this comment.
Should the pointer_lock_position not also be part of InputState?
| } | ||
|
|
||
| // TODO: Document the difference between this and EditorMouseState | ||
| // TODO: Document the difference between this and EditorPointerState |
There was a problem hiding this comment.
Perhaps this todo comment could be addressed instead of just updated? It seems like the only difference is one has ViewportPosition and one has EditorPosition.
I think that it should be reasonably easy to remove the PointerState entirely and just use the EditorPointerState (computing the other position using the viewport data which is usually available). Thoughts?
2 participants
winit bump not 100% necessary. Some more drawing tablet edge cases have been addressed that I never saw. But might as well do the update now that i touch that code anyway. Could be separated out if that is wanted.
Everything else is pretty well described with the commit messages.