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

Desktop: let the user choose which sidebar tabs are shown; hide Downloads without a client; Autotag off by default #25

New Issue
Closed
opened 2026-08-18 05:55:00 +00:00 by logan · 1 comment
logan commented 2026-08-18 05:55:00 +00:00
Collaborator
Copy Link
Copy Source

Report

There are too many sidebar tabs. Make them individually toggleable in settings. Additionally: the Downloads tab should only be present when a download client is configured, and Autotag should be off by default and turned on by the user.

Findings

  • frontend/src/components/sidebar/app-sidebar.ts ~lines 199-209 hardcodes eleven items: home, playlists, artists, genres, albums, tracks, explore, downloads, autotag, jobs, settings.
  • downloadStore.available already exists and is what explore-album-details uses to decide whether it can offer a download (canDownload), so the Downloads condition has its signal already.
  • bottom-nav shows four destinations plus "More", which is the same list filtered — a toggle has to feed both, and the "More" drawer renders the same <app-sidebar>.
  • The sidebar's item count is one of the two reasons the window minimum is 600px tall, so this partly relieves that too.

Direction

A config list of enabled views (default: everything except Autotag; Downloads additionally gated on downloadStore.available), edited from Settings. Settings itself must never be hideable. A hidden view should still be reachable by direct navigation, since detail views navigate into some of these — hiding a nav item must not break navigate.

**Report** There are too many sidebar tabs. Make them individually toggleable in settings. Additionally: the Downloads tab should only be present when a download client is configured, and Autotag should be off by default and turned on by the user. **Findings** - `frontend/src/components/sidebar/app-sidebar.ts` ~lines 199-209 hardcodes eleven items: home, playlists, artists, genres, albums, tracks, explore, downloads, autotag, jobs, settings. - `downloadStore.available` already exists and is what `explore-album-details` uses to decide whether it can offer a download (`canDownload`), so the Downloads condition has its signal already. - `bottom-nav` shows four destinations plus "More", which is the same list filtered — a toggle has to feed both, and the "More" drawer renders the same `<app-sidebar>`. - The sidebar's item count is one of the two reasons the window minimum is 600px tall, so this partly relieves that too. **Direction** A config list of enabled views (default: everything except Autotag; Downloads additionally gated on `downloadStore.available`), edited from Settings. Settings itself must never be hideable. A hidden view should still be *reachable* by direct navigation, since detail views navigate into some of these — hiding a nav item must not break `navigate`.
logan self-assigned this 2026-08-19 23:11:27 +00:00
logan added the
Status
In Progress
 label 2026-08-19 23:11:28 +00:00
logan commented 2026-08-19 23:11:28 +00:00
Author
Collaborator
Copy Link
Copy Source

Claiming. Branch: feat/25-configurable-sidebar-tabs.

Approach. A per-view visibility map in GeneralConfig
(ViewVisibility map[string]bool) — not a HiddenViews list and not
eleven booleans. An absent key means "that view's own default", so a
fresh install, an existing config with no such key, a view added later
and a view removed later (#27 deletes Jobs) all need no migration
and no cleanup. That is the polarity AllowMeteredCatalogDownload
established: the zero value is the intended answer, which a
HiddenViews []string cannot give here — its zero value is "hide
nothing", and Autotag has to be hidden by default.

Autotag defaults to hidden, everything else visible. Downloads is
additionally gated on downloadStore.available, reactively, so
configuring a client makes the tab appear without a restart (#37's
rule).

app-sidebar filters its navItems through it. bottom-nav's four
fixed tabs deliberately do not — see the ordering/scope comment I am
about to leave on #73 — while the <app-sidebar> inside its "More"
drawer inherits the filter for free, which is the point of that reuse.

A hidden view stays reachable by navigate, and needs no special case:
#72 moved the highlight onto active-view-store, so app-sidebar only
asks isActive(id) per rendered item and a hidden view lights
nothing, exactly as a detail view does.

Settings is refused by the config setter, not merely disabled in
Settings' own checkbox list: config.toml is hand-editable and an app
that can be locked out of its own Settings by a typo is a support
problem you cannot debug remotely.

Correcting one finding in the report. The fourth finding says the
sidebar's item count is one of the two reasons MinHeight is 600. Both
of those reasons have since expired — backend/config/window.go records
that the subtitle is display: none from 899px down and the sidebar
host is overflow-y: auto (at 600x460 its scrollHeight is 434 against
a 332px client, Settings reachable by scrolling). 800x600 survives as a
comfort floor, not a correctness one. So hiding tabs buys nothing there
and I will not claim it does.

Claiming. Branch: `feat/25-configurable-sidebar-tabs`. **Approach.** A per-view visibility map in `GeneralConfig` (`ViewVisibility map[string]bool`) — not a `HiddenViews` list and not eleven booleans. An *absent* key means "that view's own default", so a fresh install, an existing config with no such key, a view added later and a view **removed** later (#27 deletes Jobs) all need no migration and no cleanup. That is the polarity `AllowMeteredCatalogDownload` established: the zero value is the intended answer, which a `HiddenViews []string` cannot give here — its zero value is "hide nothing", and Autotag has to be hidden by default. Autotag defaults to hidden, everything else visible. Downloads is additionally gated on `downloadStore.available`, reactively, so configuring a client makes the tab appear without a restart (#37's rule). `app-sidebar` filters its `navItems` through it. `bottom-nav`'s four fixed tabs deliberately do not — see the ordering/scope comment I am about to leave on #73 — while the `<app-sidebar>` inside its "More" drawer inherits the filter for free, which is the point of that reuse. A hidden view stays reachable by `navigate`, and needs no special case: #72 moved the highlight onto `active-view-store`, so `app-sidebar` only asks `isActive(id)` per *rendered* item and a hidden view lights nothing, exactly as a detail view does. Settings is refused by the **config setter**, not merely disabled in Settings' own checkbox list: `config.toml` is hand-editable and an app that can be locked out of its own Settings by a typo is a support problem you cannot debug remotely. **Correcting one finding in the report.** The fourth finding says the sidebar's item count is one of the two reasons `MinHeight` is 600. Both of those reasons have since expired — `backend/config/window.go` records that the subtitle is `display: none` from 899px down and the sidebar host is `overflow-y: auto` (at 600x460 its `scrollHeight` is 434 against a 332px client, Settings reachable by scrolling). 800x600 survives as a comfort floor, not a correctness one. So hiding tabs buys nothing there and I will not claim it does.
logan closed this issue 2026-08-19 23:46:23 +00:00
gitea-actions bot removed the
Status
In Progress
 label 2026-08-19 23:46:34 +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/Settings Area/Shell-Nav Kind/Feature Platform/Desktop
Priority
Medium
3
Reviewed
Confirmed
1
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees logan
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#25