feat(editor): add editable cursor motion paths - #113
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Ten of the files this draft touches are gone. Suggestion: close this draft and rebuild the cursor-motion editor against the v4 editor in |
|
Scratch what I said about closing this — I got it wrong. The code is stale, but the proposal isn't: the interaction model, the presets, the split-at-rests idea all survive the refactor, and no issue captures them anywhere else. Closing would throw the idea out with the diff. Leaving it open. If you pick it back up, |
|
Follow-up on keeping this open: I've built the half that isn't yours to rebuild. Branch It carries your motion model from the scene JSON into the compositor:
The part worth knowing: preview and export both consume the same What's left is the feature itself, and it's yours: the editor UI (draggable control points, timeline segments, inspector) and the anchor discovery that produces the regions — rest detection, click splitting, manual splits. The compositor deliberately takes anchors already resolved, so that logic stays in the editor where it belongs. Hooks in the new tree: No pressure to pick it up — but the plumbing is out of the way if you do. |
|
Correction to my last comment: I pointed you at So the split is:
Its UI, though, is against The compositor work I described still stands whichever UI lands: |
Lifted verbatim from getopenscreen#116, which cannot be rebased: its base is 428 commits behind and the first commit alone conflicts on 56 files. The module itself needs none of that history -- it lands on main untouched, with its 17 tests passing and no new type errors. This is the pure model: presets, easing, speed, anchor kinds, rest and click detection, and the sampling that turns a region into a position. No rendering, no editor, no dependency on anything the 1.8.0 merge removed. Taken from getopenscreen#116 rather than getopenscreen#113. The two carry different lineages of this module, not an old and a new one: getopenscreen#116's knows about source time and crop projection, which is what its editor and preview call into. getopenscreen#113's is the shape the deleted web editor wanted. Not wired to anything yet. The timeline lane and inspector controls need an `AxcutCursorMotionRegion` on the document schema first, and getopenscreen#116's preview layer is built on Pixi, which main dropped when the preview moved to the native compositor -- that part needs rebuilding on the native overlay rather than porting. The compositor already samples these presets for preview and export (see `feat/cursor-motion-contract`), so the rendering half is done. Co-authored-by: Etienne Lescot <etiennelescot@gmail.com> Refs getopenscreen#116, getopenscreen#113
Summary
Why
The existing cursor renderer can smooth a recorded trace, but it cannot art-direct the movement between meaningful actions. A single continuous replacement path is also too coarse: pauses and clicks need to remain separate so each move can receive its own preset without making the cursor drift during an intended stop. Once split, those sections also need fast navigation and batch styling rather than repetitive per-item setup.
User impact
Editors place the playhead before recorded cursor activity and use the cursor-motion action. OpenScreen builds separate timeline items for moves and holds through the subsequent recorded clicks. Each item can be selected, styled, and sped up independently. Existing one-piece regions can be auto-split, and any selected item can be split manually at the playhead.
Increasing speed compresses motion into the end of the section, so the cursor waits longer at its source and still reaches the recorded click at exactly the original timestamp. Editors can then copy the chosen preset, speed, turns, and easing to all move sections without copying path-specific control handles.
The motion data uses normalized capture coordinates, so the editor representation is independent of Windows DPI and monitor layout. Preview and export share the same trajectory evaluator. Telemetry gaps (for example, when the cursor leaves the captured display) are not treated as false rests.
Validation
npx tsc --noEmit.npm run build-vite.Notes