[YoavLevavi]

GPUI port of #2378.

• ProjectConfiguration::locked_tracks (LockableTimelineTrack).
• GPUI: a lock button in each track's gutter. edits::with_locked_tracks wraps the clip edits that ripple other tracks (deleting, merging and retiming clips) and keeps locked tracks' segments where they were.

Testing: new deleting_a_clip_leaves_locked_tracks_in_place test, cargo test --bin cap-gpui (edits/assets), cargo test -p cap-project --lib.

🤖 Generated with Claude Code

[vercel]

@YoavLevavi is attempting to deploy a commit to the Cap Software Inc Team on Vercel.

A member of the Team first needs to authorize it.

[YoavLevavi]

@greptileai

[richiemcilroy]

Thanks for the GPUI port @YoavLevavi, wrapping the rippling edits in with_locked_tracks is a neat approach and the config stays unchanged for existing projects. A few things: 1) apps/desktop-gpui/src/editor_edits.rs:1106-1112 the new function was inserted under the existing delete_clip_segments doc comment, so that doc now belongs to with_locked_tracks and delete_clip_segments lost its doc. Please move with_locked_tracks and lockable_track above that comment block. 2) Reordering clips in the Clips sidebar still ripples every track through drop_clip_transition (editor_clips.rs:276), so a locked track moves there. Please wrap that edit too. 3) The locked_tracks doc in crates/project/src/configuration.rs:2682 mentions trims and transitions, so please match it to what is actually covered. 4) The lock button is drawn on every lane (editor_window.rs:10983) but toggles the whole track kind, so on text, mask or audio tracks with several lanes clicking one lane's lock locks all of them. Either draw it once per kind or make the tooltip say it locks the whole track. Thanks!

[richiemcilroy]

Thanks for the quick turnaround @YoavLevavi, all four points are sorted: the doc comments are back in the right place, clip reordering now goes through with_locked_tracks with a test, the locked_tracks doc matches what is covered, and the lock is drawn once per track. One more thing I spotted on the full pass: presets. preset_config (apps/desktop-gpui/src/presets.rs:142) serializes the whole project, so a preset saved while a track is locked stores lockedTracks, and apply_preset (presets.rs:155) and apply_default_preset (apps/desktop-gpui/src/editor_window.rs:7142) replace the project with the preset's config. Applying Default or any older preset therefore silently unlocks the user's tracks, and a preset saved with locks turns them on in other projects. Locks are timeline state like overlay_order, so please strip lockedTracks in preset_config and keep current.locked_tracks in both apply paths, with a test next to applying_keeps_the_current_timeline_clips_and_layer_order. Thanks!

[YoavLevavi]

Thanks @richiemcilroy, all four are addressed in 5da66c3:

1. with_locked_tracks and lockable_track now sit above delete_clip_segments' doc again.
2. Reordering in the Clips sidebar goes through with_locked_tracks. A new test checks that a locked track stays put while an unlocked one ripples when a reorder drops a transition.
3. The locked_tracks doc now lists what's covered: delete, merge, retime, reorder.
4. The lock is drawn once per track, on its first lane.