yonlu/yellowjacket
1
1
Fork 0
Code Issues 55 Pull Requests 6 Actions Packages Projects Releases 12 Wiki Activity

Let the user arrange the UI — component registry, saved layouts, an editor #95

New Issue
Open
opened 2026-08-18 20:37:44 +00:00 by yonlu · 0 comments
yonlu commented 2026-08-18 20:37:44 +00:00
Owner
Copy Link
Copy Source

Let the user arrange the UI: a registry of components that can be placed into slots (main, sidebars, top and bottom bars), a saved layout, and an editor for it. The original framing was MusicBee-style customisation.

Salvaged from phase 4 of docs/dev/roadmap.md, which is deleted. This is one of three things in that document that were genuinely never built.

This is a vision item, not scheduled work, and the shape below is what the roadmap proposed rather than a design that has been argued.

What it proposed

A ComponentRegistry keyed by id, each entry declaring a default slot, the slots it is allowed in, and its own default config — with existing components (track-list, now-playing, …) registered into it. A layout configuration on top, and an editor UI to arrange it.

Each registered component would also declare a settings schema that appears in Settings, which is the part that ages best: it is the same idea as config-section per feature, one layer more general.

What has changed since it was written, and why it needs re-arguing

The shell is no longer one layout. There is a desktop shell, a phone shell below 600px where the sidebar is replaced by <bottom-nav>, and a <now-playing-view> that composes the real transport components rather than reimplementing them. A slot model has to account for a layout that already changes shape by viewport, and "the user put the transport in the left sidebar" interacts with that badly.

Several smaller pieces of the same intent have also shipped independently and reduce what is left: configurable track-list columns, #25 (choose which sidebar tabs are shown), #47 (prebuilt themes), #49 (album art scale), #48 (top bar rework). It is worth asking whether the remaining value is a full layout editor or a handful more targeted toggles — the targeted ones are what users have actually asked for.

The constraint anything here inherits

Primary views are cached, not unmounted — index.ts keeps them in the DOM and toggles a class, which is what preserves scrollTop. So a component moved between slots is not a fresh mount, and viewActivated / viewDeactivated (utils/view-lifecycle.ts) is the seam any relocation has to go through.

Done when

There is a decision on scope. Either a registry and editor exist, or this is closed in favour of the specific toggles that replace it.

Let the user arrange the UI: a registry of components that can be placed into slots (main, sidebars, top and bottom bars), a saved layout, and an editor for it. The original framing was MusicBee-style customisation. Salvaged from phase 4 of `docs/dev/roadmap.md`, which is deleted. This is one of three things in that document that were genuinely never built. **This is a vision item, not scheduled work**, and the shape below is what the roadmap proposed rather than a design that has been argued. ## What it proposed A `ComponentRegistry` keyed by id, each entry declaring a default slot, the slots it is allowed in, and its own default config — with existing components (`track-list`, `now-playing`, …) registered into it. A layout configuration on top, and an editor UI to arrange it. Each registered component would also declare a settings schema that appears in Settings, which is the part that ages best: it is the same idea as `config-section` per feature, one layer more general. ## What has changed since it was written, and why it needs re-arguing The shell is no longer one layout. There is a desktop shell, a **phone shell below 600px** where the sidebar is replaced by `<bottom-nav>`, and a `<now-playing-view>` that composes the real transport components rather than reimplementing them. A slot model has to account for a layout that already changes shape by viewport, and "the user put the transport in the left sidebar" interacts with that badly. Several smaller pieces of the same intent have also shipped independently and reduce what is left: configurable track-list columns, #25 (choose which sidebar tabs are shown), #47 (prebuilt themes), #49 (album art scale), #48 (top bar rework). It is worth asking whether the remaining value is a full layout editor or a handful more targeted toggles — the targeted ones are what users have actually asked for. ## The constraint anything here inherits Primary views are **cached, not unmounted** — `index.ts` keeps them in the DOM and toggles a class, which is what preserves `scrollTop`. So a component moved between slots is not a fresh mount, and `viewActivated` / `viewDeactivated` (`utils/view-lifecycle.ts`) is the seam any relocation has to go through. ## Done when There is a decision on scope. Either a registry and editor exist, or this is closed in favour of the specific toggles that replace it.
yonlu added the Platform/DesktopKind/Feature
Priority
Low
4
Area/DesignArea/Shell-Nav labels 2026-08-18 20:37:44 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Area/Design Area/Shell-Nav Kind/Feature Platform/Desktop
Priority
Low
4
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#95