## Goal
Make the browse UI render from one shared component tree with two selectable themes:
- `default`
- `crt`
The long-term goal is that switching theme should load a different data profile, not fork or duplicate views.
## Why
We already moved a lot of geometry into shared layout/profile values, but the current system is still only partially theme-driven:
- grid and list/detail paths use shared components
- CRT and non-CRT mostly differ by profile values
- but some values are still ad-hoc offsets and screen-level special cases
- `BrowseLayouts.qml` is carrying mixed concerns (grid, list, detail, header, footer) under names like `defaultTile` / `crtTile`
This makes visual consistency harder to maintain and blocks clean customization.
## Desired outcome
A theme file (JSON or YAML) should describe browse layout/profile data for at least these 4 view types:
- `gamesGrid`
- `gamesList`
- `systemsGrid`
- `systemsList`
Each theme should be able to define geometry/styling for those views without changing routing or business logic.
## Non-goals
- No dynamic arbitrary QML from theme files
- No changes to input/routing/persistence logic
- No duplicated CRT vs non-CRT screen trees
## Proposed architecture
1. Introduce a real theme/profile model with semantic sections:
- `header`
- `grid`
- `list`
- `detail`
- `footer/status`
2. Replace `defaultTile` / `crtTile` naming with view-oriented profiles:
- `systemsGrid`
- `systemsList`
- `gamesGrid`
- `gamesList`
3. Keep component structure shared:
- `PagedGrid.qml`
- `BrowseList.qml`
- `BrowseDetailPane.qml`
- `BrowseListDetailView.qml`
- `TopStatusStrip.qml`
- `HeaderBar.qml`
4. Theme files should contain only data:
- spacing
- insets
- row heights
- scrollbar geometry
- divider positions
- title/footer visibility flags
- image/detail pane layout values
- corner radii
5. Application code loads either `default` or `crt` theme and maps it into typed QML-friendly profile objects.
## Migration notes
Before externalizing to JSON/YAML, normalize the current fields:
- split mixed concerns out of `BrowseLayouts.qml`
- rename fields that currently represent one-off visual corrections into semantic names
- identify which values are:
- truly global tokens
- shared browse tokens
- games-only
- systems-only
- list-only
- grid-only
## Acceptance criteria
- Same component tree used for default and CRT browse screens
- Theme switch changes visuals without changing routing logic
- No duplicated list/detail or grid view implementations
- Systems and Games each support:
- grid theme profile
- list theme profile
- Current default and CRT visuals can be reproduced from theme data
- New visual tweaks happen by editing theme/profile data first, not adding new hardcoded constants in components
## Open questions
- JSON vs YAML vs QML data object for source of truth
- Runtime theme loading vs compile-time bundled theme selection
- Whether Favorites/Recents should reuse `gamesList` profile or get dedicated profiles later
