feat(desktop): optional pointer capture (Pointer Lock) with Esc-to-release hint #60
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/VAPP-49-desktop-pointer-capture"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Add a default-off "Capture mouse" toggle to the remote-desktop pane toolbar. When armed, the first click on the canvas calls requestPointerLock(); the browser shows its native lock notice and a floating in-app "Mouse captured - press Esc to release" notice appears (a fixed-position div appended to document.body, shown/hidden on pointerlockchange and removed on teardown). Esc, the toggle going Off (which calls exitPointerLock), or any pointerlockchange to unlocked releases capture and clears the hint.
While captured the browser hides the OS cursor and delivers relative movementX/movementY deltas, so the driver accumulates them into a virtual cursor clamped to the remote dims (new clamp_cursor helper, host-tested) and maps that to the existing absolute-coordinate wire format, so no protocol change is needed (the minimal path from the issue). Clicks and wheel use the virtual cursor while locked; keyboard keeps working because the canvas is refocused on lock. The virtual cursor is seeded to the screen centre when the lock engages.
The toggle is a per-session Dioxus signal (not persisted) pushed to the wasm session via DesktopHandle::set_capture; the wasm session owns the lock and the hint so no Dioxus signal is written from a raw JS event callback. Listener now records its own EventTarget so the document-level pointerlock listeners are removed from document (not the canvas) on teardown. Adds the web-sys "Node" feature for the hint's appendChild/textContent.
Relative-motion input was not pursued (the accumulate-to-absolute path is sufficient for the first pass), so no dependent issue is filed.
#VAPP-49