Configurable sidebar destinations, Downloads gated on a client, Autotag off by default #145

Merged

logan merged 4 commits from feat/25-configurable-sidebar-tabs into main 2026-08-19 23:46:23 +00:00

Conversation 0 Commits 4 Files Changed 23

+1411 -62

4 Commits

Author	SHA1	Message	Date
logan	9da3967dd9	docs: record that destinations are configuration ... Beside the three navigation paragraphs, since it is the fourth thing the shell states about where the user can go. Two notes are measured facts rather than design: a default expressed as an *absent key* survives an existing seed, where one expressed as a zero value does not; and a spec can no longer assume a destination has a nav item.	2026-08-19 19:34:00 -04:00
logan	c8d94a8203	test(e2e): cover configurable destinations; stop assuming a nav item ... The assertions are about the navigation, not about the setting: "the config was saved" is the plumbing, and #69 and #72 both shipped green under specs that measured exactly that. Four existing specs reached a view by clicking its nav item, which since this change is not guaranteed to exist -- Autotag is hidden by default and Downloads is absent without a download client -- so they timed out waiting for a locator that will never resolve. `navigateTo` dispatches the app's own `navigate` event, which is what every nav item, card and detail view dispatches, so it is the mechanism rather than a test-only door. Click the item when the nav is the subject. Closes #25	2026-08-19 19:33:56 -04:00
logan	43d78a731a	feat(shell): draw only the destinations the user kept ... The navigation reads the resolved map from the backend rather than holding a copy of the defaults, which would be the copy that shipped in the binary rather than the one being edited. Hiding takes away the nav item and nothing else: `navigate` still resolves a hidden view, which detail views and the launch page depend on. No special case was needed for the highlight, because #72 moved that onto `active-view-store` -- the sidebar asks `isActive(id)` per *rendered* item, so a hidden view lights nothing exactly as a detail view does. Downloads is gated at the nav on `downloadStore.available` rather than in the config, so switching it on in Settings still means what it says once a client exists, and the tab appears without a restart. `available` is false until the providers have loaded, which makes the item appear on a fresh launch rather than appearing and then vanishing. The tab bar honours the toggles too, and the reason is local rather than a general rule about phones: "More" opens the *same* `<app-sidebar>`, which filters, so an unfiltered bar would contradict its own drawer one tap away. Which four tabs is still plan 016's subset; this only removes from it, and "More" is never filtered. `services/view-meta.ts` is the destination list, on `shortcut-meta.ts`'s pattern, because Settings is now a second reader of the same labels in the same order. Two existing sidebar tests had to say which world they describe: eleven destinations now assumes a configured download client.	2026-08-19 19:33:44 -04:00
logan	a3926704cc	feat(config): make the shell's destinations configurable ... The sidebar's eleven entries are more than most libraries need, and Autotag rewrites tags on disk, which is not what a fresh install should be one click from. Stored as a map keyed by view id, where an absent key means that view's own default. A `HiddenViews []string` cannot express "Autotag off by default" -- its zero value is *hide nothing* -- and a boolean per view turns a view that later stops existing into stored garbage. With a map, an unknown key is dropped on load, a view added later gets its own default, and no install needs migrating in either direction. Same polarity as AllowMeteredCatalogDownload: the zero value is the intended answer. `Views` is also what DefaultPage now validates against, so which views exist and which may be the launch page are one list rather than two. Two states the user could not get out of are refused rather than allowed: Settings is never hideable, and the launch page is not hideable while it is the launch page. Both refuse in the *config*, not in the UI, because `config.toml` is hand-editable. On load the launch page is instead un-hidden -- there is nobody to tell, and the honest reading of "my launch page is Autotag" is that this user wants Autotag, not that their launch page should be silently reset.	2026-08-19 19:33:32 -04:00