3.3 KiB
3.3 KiB
TASK 37 — Defaults vs current layout split
Status: ✅ Complete (2026-11-10)
Idea (creator directive 2026-09-20)
The app establishes a DB of static, branded layout objects as its defaults. Today the DB is BOTH the
defaults and the live workspace: LayoutStore.Save deletes and reinserts the whole layout on every
save, so "your last edit" and "the defaults" occupy the same rows. The recurring "reorder doesn't
persist" bug was a symptom of that conflation.
Store TWO data sets:
default— the established DB (branded factory scenes/layers), never mutated by user edits.current— whatever the user currently has, stamped with the build-id.
Load rule: honor current iff its build-id equals the running build's id (BuildStamp.Id),
otherwise load default. Bonus: one-click "revert to defaults" = drop current.
Two implementations were floated (config file vs second rows in the same DB); nothing decided — both are OPS acceptable to the creator. The proposed conceptual shape:
scene[0-4].layerList.[default | current].elementList
Notes / facts established while investigating
SceneCatalogonly defines the five canonical scene names; the actual default element set exists only as whatever the DB holds at first migration. There is no standalone in-code factory element set — "defaults" at migration time = a snapshot of today's DB.- SortOrder is a DB column only (not on models);
SourceandWebcamSceneConfigwere stamped with independent per-type sort counters and load appended all sources before all configs. That cross-table order bug is ALREADY FIXED (2026-09-20, unified z-space, see commit) — TASK 37 is the defaults/current data split on top of it. MainViewModel.LoadLayout(MainViewModel.cs:348) seedsSceneCatalog.AllwhenScenes.Count == 0and SaveLayoutNow deletes/reinserts everything (LayoutStore.Save.cs). Startup path:%APPDATA%\ytLlive\ytLlive.db(MainViewModel.cs:332),LayoutPathOverridetest seam.
Acceptance
- A saved
currentlayout with a matching build-id restores on start. - A
currentstamped by a different (older/newer) build-id falls back todefault. - Revert-to-default restores
defaultfor one scene or all.
Shipped 2026-11-10
- Current scene/source tables remain the live workspace. One-time
Default*snapshot tables and background-path settings live in the same SQLite file; schema additions are mirrored into the snapshots. Existing profiles promote their saved layout once; a fresh profile snapshots its seeded layout before creator edits. Default asset references are retained during current-layout saves. - Startup restores the snapshot transactionally when the current build stamp differs. Matching builds keep the saved current layout. Camera identity is never replaced by a layout restore; default scene placements are rebound to the creator's currently selected camera.
- App Settings offers Restore staged scene and Restore all scenes, disabled while live or recording. A one-scene reset saves pending changes in other scenes and keeps that scene staged.
- Integration coverage:
LayoutStoreSnapshotTestsandLayoutResetIntegrationTests. 615 tests green; clean build, 0 warnings.
Cross-references
ai.md— persistence architecture;MyMistakes.md— prior reorder persistence failures.