# Lane nesting interaction notes Status: design note, 2026-10-01. This records the interaction before more lane UI is implemented. ## The capability that must not be lost A lane owns temporal placement, but a symbol instance is still a doorway into another symbol. A drawing accidentally authored at the root must be movable into an instance in any lane, including another lane, without changing its visible position or timing. That operation already exists as `nest/move-node`. It resolves the source and destination at the current root frame, transplants the node, and re-expresses its transform and time under the new parent. The lane UI must expose a target path for it; it must not replace it with a weaker `:parent` assignment. There are therefore two different drag intentions: 1. **Temporal move:** drag a clip body onto lane space. It remains a clip in a lane, moves in time, and claims the destination interval by trimming/removing incumbents. 2. **Structural move:** drag from the clip's grab affordance onto another symbol instance. The dragged node is transplanted into the target instance's source symbol with `nest/move-node`, preserving its world transform and root timing. These cannot be inferred from overlap alone. Dropping clip A onto time occupied by clip B already means “A claims that time and trims B.” Structural nesting therefore needs an explicit grab affordance/mode. Its cursor is `grab` and `grabbing`; trim edges keep their resize cursors and the ordinary body keeps its timeline-move behavior. Both visible clip blocks and an expanded symbol header are structural drop targets. This permits moving a root drawing directly into `symbol-3` even when its lane is collapsed. ## Compact expansion: one selected-clip portal Expanding a lane must not restore row-per-clip vertical growth. Instead, an expanded lane reveals exactly one clip portal: the currently selected clip in that lane. ```text ▾ foreground lane [symbol-1][symbol-2][symbol-3] ▾ symbol-3 instance/source header and drop target ▸ body lane nested rows, mapped to the root ruler ▸ face lane position nested keyframes mapped to root time ``` - Selecting another block in the same lane swaps the portal in place. - With no selected clip in that lane, expansion shows a compact “select a clip to inspect” row. It must not follow the playhead during playback; that would make the timeline restructure itself while playing. - The portal header represents the selected instance and is the structural drop target for moving root or sibling content into its source symbol. - Sub-expanding the portal uses the existing recursive symbol-row walk. Nested lanes and channels are mapped through the instance clock into the open/root ruler, as ordinary expanded instances already are. - The lane's own transform/channel rows remain available separately. They affect every clip in the lane and are not properties of the selected portal. This keeps the cost of inspection constant: an expanded lane adds one selected symbol branch, not one branch for every temporal clip it contains. ## Keyframe visibility Two levels should be visible without changing editors: - The selected clip's instance-level keys (transform, visibility, corrections) appear as ticks inside that clip block on the lane row. - Expanding the lane opens the selected clip portal, where source-symbol and recursively nested keys appear on their own rows, mapped to root time. Thus the collapsed lane answers “where does this clip change?” and the expanded portal answers “which property inside this symbol changes?” The second view is still the root timeline; entering the symbol is not required merely to see or edit its keys. ## Drag targets and feedback - Grab onto lane background: move/adopt the instance into that lane. - Grab onto a symbol clip: structurally transplant into that clip's source symbol. - Grab onto the expanded portal header: the same structural transplant, with a larger and less ambiguous target. - Grab onto itself or one of its descendants: refuse before drop to prevent a symbol cycle. - A structural target receives an inset highlight and the preview stays in that target. A lane-time target receives the dashed temporal clip preview. - Successful structural drops expand the target lane and select the moved node beneath the target portal, so the result is immediately visible. ## Data model consequence No lane-as-symbol type is required. The hierarchy remains: ```text symbol -> sequence lane -> instance clip -> source symbol -> its lanes/nodes ``` Lane membership owns time partitioning. Symbol instances own composition nesting. The UI may present the selected instance below its lane, but that is a derived portal, not another ownership edge and not a duplicated node. ## Implementation order 1. ~~Render instance-level key ticks within lane clips.~~ Done: a clip's keys are on its block, drawn after the blocks so they land on the one they belong to. 2. ~~Add selected-clip portal expansion to `timeline/rows`.~~ Done, with two additions the note did not anticipate: - The portal is chosen by the whole LINEAGE of the selection, not the selected id. Selecting a shape inside the clip, or the end of its span, is still working inside that clip, and matching the id alone closed the portal the moment anything under it was touched. - A HELD clip opens too. `clip/source-time` is nil for a hold, so the walk used to stop there and the inside of every drawing was unreachable from the root timeline. Its rows are now shown across the hold and marked `:unmapped?`: no keys, and no draggable edges, because no frame inside it has a place on this ruler. 3. ~~Add the explicit structural affordance.~~ Done as SHIFT on a clip-body drag rather than a separate grab handle: shift turns a temporal move into a structural one, the target clip takes an inset highlight, and a label by the pointer says which of the two is about to happen. 4. Route structural drops through `nest/move-node`. **Wired, and blocked in the domain.** The gesture asks `nest/move-refusal` on the way past, so the label says before the drop what the command would say after it. Two refusals stand in the way of ordinary use: - *both have to be on screen at this frame.* Inherent, and worth keeping: the move preserves the world transform and there is no common frame to preserve it at otherwise. It does mean nesting one clip into another in the SAME lane can never work — a lane never overlaps itself — so this is a between-lanes gesture with the playhead somewhere both are showing. - *a held or looping clip has no clock to move through.* `nest/inside` returns no `:time` for a hold, and a held one-frame drawing is the most common thing in a document, so today nesting into one is refused — which is most of what anybody would try. 5. After the transplant, expand the destination portal and reveal/select the moved row. `::ui/move-node` already selects the moved node and opens the rows down to it; the portal follows from the lineage rule in 2. ## The held destination, unresolved A held cel shows ONE source frame for its whole span, so there is no invertible map from the lane's frames to the drawing's and `move-node` refuses. But the refusal is stronger than the facts require. Inside a frozen destination only one frame is ever observed, so: - the RATE of any map into it is unobservable — every rate shows frame `in`; - what IS observable is that the moved node should show, at that one frame, what it shows now at the current root frame. That pins a unique sensible answer — rate 1, aligned so the current frame maps to the shown frame — and nothing else about the mapping can be seen. If that argument holds, it is a rule rather than a guess, and it is the difference between structural nesting working for drawings and not working at all. It needs its own proof: a drawing authored at the root, nested into a held cel in another lane, sampled before and after to show the same picture, in the style of `drawn` in `lane_test`.