noe/arthur

Your Name 2dc5735ded The timeline opens the whole document

Making a lane one row cost the thing a row was for. A clip stopped being a row,
so there was no longer any way to open a clip and see what was inside it, and
the inside of a drawing — the most ordinary thing in the document — became
reachable only by opening it as its own tab. This is that capability back,
from the root timeline, down as far as it goes.

An expanded lane opens exactly ONE clip: the selected one. Its own keys, then
the lanes and nodes of the symbol it places, then theirs, each mapped into this
ruler by the recursive walk that was already there. Twelve clips in a lane
still cost one row, and inspection costs one branch rather than twelve.

Two things that only showed up once it ran. The portal is chosen by the whole
LINEAGE of the selection and not by 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 shut the portal the instant anything under it was
touched. And selecting now waits for the pointer to come UP, because selecting
on the way down re-drew the timeline before the gesture had said anything: it
shut the portal holding the lane being dragged INTO, out from under the
pointer.

A HELD clip opens too, which the old row walk never did either. `source-time`
is nil for a hold, so the walk stopped there and the contents of every drawing
were invisible from here. Its rows are shown across the hold — which is when
the node is on screen — and marked `:unmapped?`: no keys, and no draggable
edges, because a frozen clock gives no frame inside it a place on this ruler.
Refusing to place the keys is the honest half; refusing to show the rows was
not.

Double-clicking a clip opens the symbol it places as a tab, as double-clicking
the same symbol in the pool does. That was already written and had never once
run: the track captures the pointer for a slide, so the click and double-click
that follow are delivered to the track and never to the block. The track now
resolves them itself. Fixing the delivery exposed two more: `symbol/lineage`
reported a `parent cycle` for any id in a symbol with NO nodes, because a
one-element chain is longer than zero nodes — and opening a symbol left the
selection pointing into the symbol being left, which the breadcrumb and the
inspector then tried to resolve. The editor unmounted. Both are fixed where
they were wrong, and the browser test asserts the editor is still standing
afterwards.

Audio is a clip in a lane like everything else. A dropped sound lands in one
and is trimmed and moved by the same commands; a lane holds picture or sound
and not both, which is the explicit capability the model asked for rather than
a guess per frame. The refusal lives in the commands and not only in
validation, because placement claims time: `blank` would have deleted the
sound to make room for the picture and left a perfectly valid document behind.
What is in a lane of the open symbol is drawn as a lane; what is nested inside
a placed symbol is still flattened by `audio-tracks`, so no sound is on two
rows.

Everything that enters the timeline now enters a lane: a converted take, a
symbol brought in from another project, a sound. One rule answers where —
`lane-destination` — and every symbol is born with a lane for it to answer
with. An unaimed drop fills an EMPTY lane rather than taking an occupied one
nobody pointed at, because the alternative is trimming away what was there to
make room for what was dropped.

Shift during a clip-body drag means the other intention: put this node INSIDE
the symbol the clip under the pointer places, through `nest/move-node`, which
is what keeps the world transform and the root timing. Overlap cannot say
which of the two is meant — dropping on occupied time already means claiming
it — so the person says, and a label by the pointer says it back. The label
asks `nest/move-refusal`, the same check the command makes, so it cannot
promise what the drop would refuse. Today it refuses more than it allows:
both clips have to be on screen at one frame, which two clips in one lane
never are, and a held destination has no clock to move through at all.
`docs/lane-nesting-notes.md` argues that the second refusal is stronger than
the facts require and says what would settle it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-10-01 16:13:02 -04:00

8.1 KiB

Raw Blame History

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:

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.
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.

▾ 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:

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

~~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.
~~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.
~~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.
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.
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.

8.1 KiB Raw Blame History