63 lines
3.3 KiB
Markdown
63 lines
3.3 KiB
Markdown
# 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
|
|
|
|
- `SceneCatalog` only 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); `Source` and `WebcamSceneConfig` were 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) seeds `SceneCatalog.All` when `Scenes.Count == 0`
|
|
and SaveLayoutNow deletes/reinserts everything (LayoutStore.Save.cs). Startup path:
|
|
`%APPDATA%\ytLlive\ytLlive.db` (MainViewModel.cs:332), `LayoutPathOverride` test seam.
|
|
|
|
## Acceptance
|
|
|
|
- A saved `current` layout with a matching build-id restores on start.
|
|
- A `current` stamped by a different (older/newer) build-id falls back to `default`.
|
|
- Revert-to-default restores `default` for 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: `LayoutStoreSnapshotTests` and `LayoutResetIntegrationTests`.
|
|
**615 tests green; clean build, 0 warnings.**
|
|
|
|
## Cross-references
|
|
|
|
- `ai.md` — persistence architecture; `MyMistakes.md` — prior reorder persistence failures.
|