Commit Graph
104 Commits
Author SHA1 Message Date
vicrodh 750c59034b feat(qt): Excel-style multi-select — Shift ranges across every surface
Selection existed but had no keyboard: every click was a single toggle,
so picking 40 tracks meant 40 clicks. Slint and Tauri have had ranges
since 2026-06; this is that port.

NINE surfaces, not the five the track views suggested: Album, Artist,
Playlist, Label, Local Album, plus Library's tracks and albums and Local
Library's tracks and albums. Each carried its own hand-copied `selected`
map and its own `toggleSelected`, so the rule went into
controls/SelectionModel.qml and the maps stayed where they were — the
smallest change that stops it being copied a tenth time.

The rules are Tauri's `applyShiftRange`, unchanged: a plain click
toggles one row without clearing the rest, Shift fills the range from
the anchor ADDITIVELY (so re-dragging a range cannot eat the set) and
leaves the anchor where it is, and Ctrl/Cmd is the same as a plain click
— not a shortcut, but the behaviour both references already have,
because an accumulating click is what "add without disturbing" means.

Qt makes this CHEAPER than Slint, and the difference is worth recording:
Slint had no modifiers at click time and had to read a thread-local set
from a ModifiersChanged handler, with a documented stale-read edge case
when the window lost focus mid-chord. A QML MouseArea delivers
`mouse.modifiers` on the event itself, so the modifier and the click can
never disagree and no such seam exists here.

Three judgement calls, stated because they are not forced:

  - Library gets TWO models, one per kind. Its rows are mixed, and one
    anchor would let a Shift-click on a track sweep up the albums drawn
    between it and the anchor.
  - Ranges run over the VISIBLE rows. Local Library's search box is a
    view filter, and a range over rows the user cannot see is not the
    range they asked for — the same call `select-all` already made.
  - The Local Library tree rail keeps plain toggles. Its selection lives
    in Rust (QbzLocal.treeToggle*Select), so there is no QML map to hang
    an anchor off; teaching the Rust side about an anchor is its own
    change, and the file says so where a reader would expect otherwise.

The anchor is an ID, not an index, because every one of these views can
re-sort or filter under a live selection — an index anchor silently
points at a different track the moment the order changes. Slint's
selection.rs made the same call for the same reason.

Verified by driving the app: in Abbey Road, click row 1 then Shift-click
row 5 selects exactly rows 1-5 and leaves 6-8 untouched, with the bar
reading "5 selected"; the same in a playlist, additively over a row that
was already selected.

cc
2026-08-22 02:03:10 -06:00
vicrodh 7fc7605887 feat(search): the Tracks results use the app's full track row
Search already mounted the shared TrackRow, but had never switched on
any of its affordances: no artwork, no artist link, no album column. So
the one surface where people are most often hunting for an album gave
them no way to reach it except the context menu's "Go to", three clicks
deep, while every other track list in the app links straight through.

Turning the arms on is most of it. The missing half was in Rust:
`search_qt::TrackRow` carried `albumId` but not the album TITLE, and the
row draws `item.album` as the column's label and uses `item.albumId` for
the click — so without the title the column would render empty and the
link would be invisible. `track.album` was already being read one line
above for the id.

No layout work: TrackCols already reserves the album cell and its gap
behind the same `showAlbum` flag, so the widths redistribute themselves.

Verified by driving the app: a search for "beatles", the Tracks tab, and
a click on "Abbey Road" in a row opens Abbey Road (Super Deluxe Edition).

cc
2026-08-22 01:43:50 -06:00
vicrodh f50c1b5188 feat(settings): the library folder table becomes its own page
The folder block — toolbar, add-path row, filter, the row-per-folder
table and the scan progress — is the tallest thing in Settings and it
sat at the TOP of Local Library, pushing Albums view, Library > All,
Maintenance, Danger zone and the three media servers off the first
screen. Behind a Manage row, the whole panel fits one screen again.

The shape is the one Blacklist already uses for its manager, and this
view is deliberately its twin: same 64px summary row, same metrics, same
route-recorded-by-the-caller contract.

Nothing about the table changed. LibraryFolderTable.qml is mounted
verbatim, still driven by the settings document and still acting through
the settingsString action keys.

Two things had to travel with it, because SettingsView used to supply
them and a routed page has no access to that:

  - LibFolderEditModal, or the per-folder pencil would open nothing,
    silently.
  - the refresh on entry. A view reached by Back runs no per-view load,
    so it asks for its own, where BlacklistManagerView puts its reload.

Verified in a running window: the route mounts, the seven folders render
with their per-row actions, and Back returns to Local Library with the
section intact.

cc
2026-08-22 00:01:13 -06:00
vicrodh dc8cb1fa32 perf(qt): build only the discover rails that fit the viewport
2026-08-17 fixed the four Discover tabs, which were all instantiated
because `visible: false` hides an item without stopping QML from
building it. This is the same disease one level down and it is what was
left: a Repeater builds EVERY delegate in its model, so a ten-section
tab built ten rails, each rail's horizontal ListView then created its
own delegates during the first layout pass, and the viewport has room
for about two and a half.

That work is what `to-idle` was made of — the rails nobody could see
paying for their cards before the GUI thread could reach the event loop
and let a frame out.

The seed is one viewport and the rest arrive after the first frame. A
rail is ~328px with the Column spacing against a ~740px pane, so three
covers the fold; +2 per tick reaches even the twelve-section For You tab
inside ~80 ms. The `active &&` on the visibility gate is load-bearing:
a Column skips invisible children entirely, but an active:false Loader
is visible and 0px tall, which would reserve a spacing slot per pending
rail and collapse it as the rail lands.

Honest limit: this did NOT turn out to be what fills the blank stretch
between the acknowledgement frame and the content. Library has no such
ramp and shows the same shape, so that hypothesis is refuted and the
remainder is unattributed.

cc
2026-08-21 23:59:29 -06:00
vicrodh 2273db9184 feat(qt): the disc surfaces — rip wizard, metadata correction, and a pane that
can be read

RIP WIZARD, three steps, each answering something the first version got wrong
by not asking. What will happen — which disc, how many tracks, and that the
output is FLAC, stated rather than implied. The tracks, editable, because a
CD-DA carries no titles at all so "named wrong" is the ordinary case and once
files are on disk it is a rename job. And what happens afterwards: a ripped
album the library cannot see is a folder full of files, so the destination is
compared against the registered folders — by path COMPONENTS, not by string
prefix, since /music-backup starts with /music and is not inside it — and the
right follow-up is offered, naming the folder it would re-scan. "Do nothing" is
an explicit choice rather than the silent default. The follow-up runs only on
success.

Tracks can be deselected. Everything is ticked on arrival and the user goes
from all to fewer; a wizard that starts empty makes the common case the one
that costs the most clicks. On the Rust side an absent `selected` means yes, so
an older form cannot silently rip nothing.

A PROGRESS PANEL behind the ripping chip, which is a door rather than a label:
it is the only thing on screen during a rip and the two questions it could not
answer are the ones that matter. A soft lock says not to eject — soft because
nothing here can hold a tray shut, so the honest move is to say it and keep
saying it. Per-track state with a bar on the row that is actually moving.
Stopping is offered, deletes nothing, and says so; a cancelled job does not
jump to 100 %, which is the one lie a progress bar must not tell.

CORRECT DISC DETAILS, for a CD and a SACD image and for neither on a folder,
which has no identity to write a correction under. The list shows what
distinguishes four pressings of one album rather than four identical titles,
and flags a track count that disagrees with the disc. Selecting is not
applying: the candidate is fetched in full and its track list shown, because
that list is the only thing proving a plausible title is the right pressing.
Applying renames the live session without renumbering ids — a re-open would
orphan a playing track — and writes a user row. Only MusicBrainz re-resolves
the cover; Discogs ids are not Cover Art Archive keys and a wrong cover is
worse than the old one. The correction can be dropped, because without an
escape a bad apply is permanent and that makes people afraid of the button.

THE PANE SPLITS BY DISC. A box set scans as one album — measured on a 34-track
set whose album_group_key is the box root for every file while the disc number
sits in the data unused — so the pane was a flat list 247 rows long. The key
carries the disc, unconditionally, because it round-trips through the play-album
lookup. Its own client-side filter over what is already rendered, since finding
one track meant scrolling past the other 246.

EPHEMERAL TRACKS LOSE WHAT CANNOT OUTLIVE THEM. queue_qt has published
isEphemeral on every row for a while and the queue panel respected it; the bar
never read it. The heart goes inert, the add menu keeps only its queue actions,
and the row menu comes back with those three and nothing else. Absent rather
than rendered-and-inert.

Also: a spinner on Open that blocks a second click onto a drive already being
read, held by a counting RAII guard because opening is a relay and the chip
must not blink off in the seam; the now-playing card routes a disc to the pane
it came from instead of to an album id no catalogue can open; the file pickers
use rfd, the platform's own dialog, which the POC-NOTE said was a five-line
change once the dependency existed — it existed, Settings had been calling it
from this crate for weeks, and on macOS the four Linux choosers do not exist so
Open folder and Open SACD image opened nothing at all, in silence; the empty
state stands down for the Open pane, which on a machine with no library drew
both fully painted; tooltips on every disc control through one hover() helper,
since two call sites had already mismatched their key, which does not fail —
the bubble simply never goes away.

cc
2026-08-21 18:58:22 -06:00
vicrodh a922bdd316 feat(qt): disc covers, a corner close, and an icon for Rip
Three things the owner asked for after driving the first build.

COVER ART. A SACD image carries none, but the file it was downloaded as
almost always sits beside one — `cover.jpg` next to the `.iso`, or one level
up when the rip is split into "Disc 1"/"Disc 2" folders, which is the shape of
the owner's Rheingold. `find_folder_artwork` already knows that walk, so this
reuses it rather than growing a second rule about where covers live.

CLOSE moves to the pane's top-right corner, for all three media. It used to
sit in the action row beside Shuffle — a destructive action one pixel from
"play", which is where a hand goes without looking. It is also OUTSIDE the
Flickable now: scrolling a 24-track disc must not carry the only way to close
the session off the top of the screen.

THE RIP ICON is a disc with a folder, drawn as a Lucide-style outline rather
than traced from the owner's PNG. The argument is the size it renders at: at
15px a solid, detailed glyph turns to mush while an outline still reads, and
the comparison was rendered at both sizes before choosing.

Adding it also found a gap in my own tooling. `icon_tint_qt.rs` re-tints from
MASTERS at theme-change time, and `masters_cover_every_shipped_glyph` failed
the build for a glyph that was baked but had no master — six files written,
one line forgotten. `bake_icon.py` now registers the master itself, because a
step that has to be remembered is a step that eventually is not.

cc
2026-08-21 09:07:59 -06:00
vicrodh bbce651d79 feat(qt): a Rip button on an open CD, and it asks where to put the album
The button lives on the ephemeral pane's header and appears only for a
PHYSICAL disc — an image is already a file, so offering to rip one would be
offering to copy something the user already has. Whether the session is a disc
is DERIVED from its rows rather than passed in: a flag somebody has to
remember to set is a flag that eventually is not.

The destination is always asked. The app knows several plausible music folders,
which is exactly why it must not pick one — a ripper that decides where your
music goes is a ripper you clean up after.

While a rip runs the button gives way to its progress ("3/7 · 45%") and a
spinner: one control, one state, rather than a button that looks pressable
during a job it cannot start twice. The bar is per-DISC and not per-track,
because a listener watching a 79-minute album wants to know how far the ALBUM
is, and a per-track bar that resets seven times reads like a stall.

Driven end to end on the owner's Fear Inoculum: seven tracks written into
"Tool - Fear Inoculum/", every one decoding clean and seekable, all tagged,
no `.part` left behind.

Four new strings in all eight locales.

cc
2026-08-21 02:27:40 -06:00
vicrodh 452589ddaa feat(qt): open a SACD image and play it — the disc names itself
`Open > Open SACD image…` picks a .iso, reads its stereo area and publishes it
as the ephemeral session. Nothing lands in library.db.

Unlike a CD, a SACD needs no network to be named: the Master TOC carries the
album title and artist, and the area TOC a title per track. The owner's disc
opens as "Wagner: Das Rheingold", 24 tracks, every one with its German title
and "Berliner Philharmoniker, Herbert von Karajan, etc." — all of it read off
the image.

Routing is one line in `LocalSource::playback` and none in the player: a
`sacd:` reference rides the existing DsdFile ticket, because `open_dsd` is the
funnel all six player-side DSD constructions already go through. Teaching it
there is what makes the PCM, DoP, native and gapless paths inherit disc images
for free.

Driven end to end on the owner's Rheingold: the tab reads "Wagner: Das
Rheingold 24", the badges read HI-RES / DSD64, and pressing play took the DoP
route —

  Player: DSD track — DSD64 via DoP (176400 Hz carrier)
  [ALSA Direct] DoP hardware configured: 176400Hz, 2ch, S32_LE
  Audio thread: DoP playback STARTED

which is the outcome that matters: the disc's DSD bits reach the DAC without
being converted to PCM at all.

Six new strings in all eight locales. Unsupported cases are named rather than
approximated — a multichannel-only area, a DST-compressed one and a file that
is not an image each get their own message.

cc
2026-08-21 01:34:23 -06:00
vicrodh d9893b659a feat(qt): open the audio CD in the drive and play it
`Open > Open audio CD` reads the disc, builds an ephemeral session and lands
on its tab. Nothing touches library.db, which is the whole point of the
ephemeral path: a disc is content from outside the index that leaves with the
plastic.

It does not invent metadata. CD-DA carries no titles, and the disc measured
here reports its MCN as all zeros, so tracks are "Track N" and the album is
"Audio CD". A DiscID lookup is the obvious next step and is deliberately not
faked: a wrong title is worse than an honest number.

The feeder is the interesting part, and its liveness check took three designs
because the first two were wrong in opposite directions — both caught by
driving the app, neither by any test:

  1. `current_track_id() != play_id`: `play_streaming` posts to the audio
     thread and returns, so the id is not ours yet and the feeder retires
     before reading a sector. Nothing played at all.
  2. The same test with a wall-clock grace: a DEADLOCK. That field is stored
     only once the audio thread starts playback, which needs the initial
     buffer, which is what the feeder is filling. Waiting on it is waiting on
     ourselves; the grace expired and the track stopped mid-play.
  3. A feeder slot the audio thread plays no part in. A newer disc play claims
     it and the older thread retires on its next block. The acknowledgement
     path stays for "something else superseded us", but only AFTER the player
     confirms our id, and with no timeout — a timeout is what kills a healthy
     feeder.

A 16-bit WAV header, not `qbz_dsd`'s: that one is hardcoded to 24-bit, and
reusing it would either lie in the header or promote 16-bit samples to 24.
The shift is arithmetically lossless but it makes the DAC open at 24 bits for
a 16-bit source, which is precisely the silent conversion a bit-perfect path
must not contain. `play_streaming` also does not publish bit depth, so the CD
states 44 100/16 explicitly instead of inheriting the previous track's.

Driven end to end on the owner's disc: seven tracks with the right durations,
CD / 16-bit / 44.1 kHz badges, ALSA Direct opened at 44100 Hz in exclusive
mode, playback past 2:25 with no read errors, and two rapid skips retiring
their feeders in ~160 ms each.

Seven new strings in all eight locales.

cc
2026-08-20 23:29:21 -06:00
vicrodh 0e9721d24b refactor(qt): reorder the Local Library header and label the Open menu
Owner's layout: the two maintenance glyphs sit together and the action that
produces new content reads last —

    Local Library  (settings) (resync)  [folder] Open v

Open also stops being a bare glyph. A folder icon on its own reads as "browse
folders" when there is a tab literally called Folders two rows below, and this
control is the one door for every medium the pane can hold: a folder now, a CD
and a SACD image next. It is a 30px / radius-6 chip with icon, label and
chevron — the same small toolbar-control contract this header's selects use.

cc
2026-08-20 22:24:11 -06:00
vicrodh 9666ef129e feat(qt): give the ephemeral pane an album header, a shuffle and zebra rows
The pane opened on a bare title, a track count and the folder PATH — a
filesystem readout for something the user is about to listen to. For the
common case this pane IS an album page: one folder, one album, one cover.

It now reads like one. The cover is 224px, the size LocalAlbumHeader uses, so
an opened folder and an indexed album never present the same record at two
different scales; the cell collapses entirely when the session has no art
rather than reserving an empty square. The second line trades the path for the
total playing time, formatted by the same `total_duration` helper every other
Local Library surface uses. Play gains a Shuffle beside it, with the same
`(shuffle)` shape `play_album` has, and the Clear stays — it is the only way
to close a session, and with it the only way to make the tab go away.

The per-block header now draws only for MULTI-album sessions. Adding the big
header made it a stutter for single-album ones: the same cover, the same
title and the same count, twice on one screen.

Track rows get `zebra: true`. `TrackRow` already had the property; this pane
was simply the surface that never set it.

The shuffle's generator was replaced before it shipped. The first version was
a bare xorshift with a comment claiming a folder shuffle "is not a place that
needs a good generator" — measured over eight consecutive shuffles of a
ten-track album, one track opened FOUR of them. It is splitmix64 now, seeded
with a counter as well as the clock so two shuffles inside one clock tick
cannot repeat, and there is a test asserting no position is pinned over 2000
runs. Shuffle quality is something the listener sees directly.

cc
2026-08-20 22:23:56 -06:00
vicrodh 45c686fab0 fix(qt): take the view to the session you just opened, every time
Reported: opening a folder left the view on whatever tab was already showing.

The handler watched `ephemeralActive`, and that flag is ALREADY true when you
open a second folder over a first — or when the boot restore opened one before
you ever touched the view. So it fired exactly once in the life of the app and
then never again, which is precisely the symptom.

It now watches an open SEQUENCE that changes on every open. The discriminator
was already in the code and did not need inventing: `open()` and `open_path()`
pass a runtime to `scan`, `rehydrate()` passes None. Bumping only for the
former is what keeps a remembered folder from stealing the tab you actually
navigated to at startup.

Also restores `onEphemeralActiveChanged`, which I deleted by accident in the
label commit: a range replacement swallowed the handler sitting between the
two edits. It is the fallback that sends you to Albums when the session closes
under you, and without it closing a session left `activeTab` pointing at a tab
that no longer exists — a blank content area. It had been smoke-tested BEFORE
that edit, so the test was valid when it ran and stale by the time it landed.

Verified in the reported scenario: standing on Albums with one session open,
opening a different folder switches to the tab, the label changes and the
count follows.

cc
2026-08-20 22:23:34 -06:00
vicrodh cb4c03ca46 feat(qt): one Open menu and one Refresh menu in the Local Library header
The ephemeral pane used to be a third arm of the Folders tab, reachable only
through a folder-open icon buried in the tree rail — one arm of one mode of
one tab. It also HID the folder browser while it was open. Neither survives
the media this pane is about to hold (a CD, a SACD image).

Row 1 of the header now carries two menus, both `CardMenu` (the shared menu
surface, no new component):

  - `Open`, always present, is the one door for every medium. Only "Open
    folder…" is wired here; the disc entries land with their readers.
  - `Refresh` replaces the Plex-only re-sync icon (#573). Rows are APPENDED
    per configured source rather than rendered disabled, so a user with no
    media servers sees local folders and nothing else. It needed no new Rust:
    `plexAvailable`, `mediaHasJellyfin`, `mediaHasSubsonic`, `syncPlex()`,
    `mediaSync()` and the settings' own "library-scan" all already existed.

The ephemeral session becomes a tab of its own, present only while a session
is. Two failure modes are handled because the tab can VANISH under the user:
closing the session falls back to Albums instead of leaving `activeTab` on a
tab with no body, and opening one navigates to it — while the pane was an arm
of Folders that was implicit, and with a tab of its own, opening a folder from
Albums would otherwise do nothing visible.

`load_tab_impl` gains an "ephemeral" arm: nothing to load (the session is in
memory), but without the arm every switch to the tab logged "unknown tab",
which is what a real routing bug looks like.

Driven under Xvfb, not inferred: both menus open, the gated rows match the
configured servers, opening lands on the tab, the badges read DSD64, closing
removes the tab and falls back to Albums, and the folder tree is now visible
WITH a session open.

cc
2026-08-20 21:14:36 -06:00
vicrodh 900517db57 fix(qt): size the filter flyout to its content, not to 372px
The Slint original sized a fixed card around THREE source chips. This
port now has five — Plex plus the two media servers — and the row ran
to the card's edge, with the last chip all but touching the border.

The 372px becomes a floor and the width is derived from the widest chip
row plus the 16px padding on each side, capped so the card can never run
past the left edge. That also survives a UI-scale bump or a language
whose labels are longer, neither of which a fixed number can.

`implicitWidth` is safe to measure here: a Row sums its children and a
non-wrapping Text reports its natural width, so nothing in the chain
reads the card width back and there is no binding loop. An invisible
chip contributes nothing, so the card is narrower when a server is not
configured.

cc
2026-08-20 16:38:28 -06:00
vicrodh 021b5609e1 feat(qt): the Albums funnel survives navigation and restarts
The filter worked but forgot itself twice over: leaving Local Library
reset it, and so did closing the app. The first one is not a bug in the
view, it is what this port does — navigating away DESTROYS the view
(project_qt_nav_eager_tabs), so a `property var filter: ({})` cannot
outlive a trip to Discover.

Both follow from one move: the funnel lives on the BRIDGE, mirrored into
the shared ui_prefs.json. The bridge outlives the view, and the file
outlives the process, so one property buys both kinds of persistence.

`setFilter()` is the only writer, so a mutator cannot change the funnel
and forget to persist it, and the view re-seeds from a Connections on
the qproperty rather than only at construction — a republish has to
reach a view that is already open.

The saved funnel is pruned where the source GATES are published, not
somewhere else, so the two can never disagree: a restored `jellyfin`
tick with no Jellyfin configured would match zero rows while the chip
that clears it is hidden by the same gate — an empty grid with a badge
counting a filter the user cannot see. Only the media-server keys are
pruned; local/offline/plex are always meaningful words.

Verified: ticked Jellyfin, went to Discover and back (badge and grid
held), restarted the process (held), pressed Clear (ui_prefs went to
{}). The prune is reasoned, not exercised — both servers are configured
on this box, so no gate is off to test it against.

cc
2026-08-20 16:38:28 -06:00
vicrodh 322b9374fb feat(qt): Jellyfin and Subsonic filter chips in Local Library
The Source row of the filter popup offered Local / Offline cache / Plex,
so a media-server library could be browsed but not narrowed — no Plex
equivalent existed for it.

Adds a chip per media server, each gated on a new bridge property so an
unconfigured server never shows a chip that can only ever return zero
rows (Subsonic stays hidden here, Jellyfin appears).

The fold in applyFilter is the part that is easy to get wrong: rows are
stamped with the BRAND the server reports — navidrome, gonic, airsonic,
astiga — while the chip is the PROTOCOL. Without folding those words to
"subsonic", ticking any source filter would silently drop every row of a
Subsonic library instead of filtering it.

Verified against the live Jellyfin bench: with the chip on, the grid
holds only Jellyfin-badged albums.

cc
2026-08-20 13:49:37 -06:00
vicrodh d5ce8bcaeb fix(qt): offline-cache rows, Jellyfin playback, and media art on the bar
Three defects the owner found by using it, all mine, all from the same
root: a source word that stops at Plex.

1. AN OFFLINE-CACHE ROW PLAYED NOTHING.

     audible: file not available at …/audio/tracks-cmaf/426056576

   `SourceId::from_word` folds `qobuz_download` into LOCAL because the row
   IS a file — but for a CMAF-cached download that "file" is the offline
   cache's own container and only `qbz-core`'s offline tier can read it.
   IC-12's first pass declared those rows ours and handed them to the
   local audible step. They now stay on the Qobuz funnel, which is where
   they were before stage 3 and where their `QueueTrack.id` — the real
   catalog id — is meant to be resolved. The symptom was the bar, the
   queue and MPRIS all changing while the previous track kept playing.

2. A JELLYFIN ROW CHANGED THE BAR AND PLAYED NOTHING.

   `local_queue_track` folded everything that was not Plex or a download
   into "local", so the row entered the queue wearing a source word that
   disagreed with its namespaced id and carrying no server id at all.
   Both media words are now arms of their own, and the hint carries the
   SERVER's item id — which `claim` prefers, because it survives a cache
   rebuild that renumbers rowids.

3. MEDIA ART NEVER REACHED THE BAR, THE QUEUE OR MPRIS.

   Those surfaces resolve an `artwork_url` string with no row in hand, so
   `classify` has only the SHAPE to go on — and a Jellyfin image tag or a
   Subsonic coverArt id has no shape worth reading. `local_queue_track`
   now stamps the token SOURCE-TAGGED (`jellyfin:<albumId>/<tag>`) and
   `classify` grows one arm that DELEGATES it to
   `registry().artwork_token` instead of guessing. One arm, not 111 call
   sites, and it shares its cache entry with the grid because it is the
   same call.

Verified in the running window: a Jellyfin album streams and plays —
`[JELLYFIN/STREAMING] 331 MB @ 12 MB/s`, decoder up, 44.1 kHz to the DAC.

429/429.

cc
2026-08-20 12:57:36 -06:00
vicrodh 3cfce8a769 feat(qt): the media-server settings panel, driven and verified in the window
ONE component instantiated twice, because it is one form twice. Every
difference between the protocols is a property set at the call site, so
they are visible in one place instead of drifting across two files:
"Test" proves the address for Jellyfin and only "a Subsonic server
answered" for Subsonic (which has no credential-free endpoint), the
password is discarded for Jellyfin and kept for Subsonic (no session,
md5(password+salt) per request), and the sync cost is stated up front —
45.8 s per 4924 tracks against 0.81 s per 6678 — so a long sweep does not
read as a hang. The credential never leaves Rust; the panel gets
`hasCredential`.

Assets: the colour marks for cards, the monochrome ones for rows. Both
mono files arrived as BLACK ink and are invisible on a dark theme
untinted, so they were normalised to the #ffffff master ink and joined
`icon_tint_qt::MASTERS` — the port's only shader-free way to recolour an
SVG per theme. The Jellyfin colour asset had a white rounded-rect plate
behind the mark; it was stripped, because every other brand mark here is
transparent and a white tile beside them reads as a rendering bug.
Rendered with Qt itself and looked at before any of it was wired.

CAVEAT, recorded in SourceIcon: the Subsonic mark is NAVIDROME's logo,
and `subsonic` covers Gonic, Airsonic, Astiga and Ampache too. `ping`
reports the server's own type and it is already persisted, so branching
later is cheap — a known wrongness, not an unnoticed one.

THREE BUGS THAT ONLY THE RUNNING WINDOW COULD SHOW, all found by
driving it under Xvfb rather than by reading the log:

1. `MediaServerSettings is not a type` — a .qml missing from build.rs is
   not in the QML module. It resolves fine on disk, compiles nothing,
   and blanks the WHOLE settings page at runtime. All three existing
   audits passed. `qml_module_registration_audit.py` is the missing
   check and is now in the gate.
2. The toggle would not move. The panel reads its state from the
   settings DOCUMENT, unlike Plex's toggle which reads a bridge
   property, so every mutation has to republish it — connect, enable,
   disconnect and the end of a sweep now do.
3. Every Jellyfin album in the grid drew the LOCAL HARD-DRIVE badge:
   `local_rows::badge_source` had never been taught the two words and
   folded them into `_ => local`. Not cosmetic — that string is what the
   source chips filter on.

`play_single_from_source` also grew the arm it needed: a media-server row
from the recently-played rail has no library.db row to mint a LocalTrack
from, so it resolves through `registry.tracks_of` instead.

END TO END, from the UI, against the real server: toggle on -> type the
address -> Connect -> "jellyfin sync: 500/4924 ... 4924 saved, 0 pruned,
4924 cached" -> Local Library shows 461 albums with their covers and the
Jellyfin badge. The cached quality distribution is identical to what the
server reported in the original protocol sweep.

428/428.

cc
2026-08-20 10:57:28 -06:00
vicrodh 321d8fe753 fix(qt): align the playlist manager's card grid with its own headings
The grid delegate carried x: 32 on the delegate ROOT. A ListView owns its
delegates' position, so an x set there is not reliably the one that survives
layout, and it did not: the cards sat about 24 px left of "Folders (12)" and
"Playlists (9)", which PmPageHead draws at 32 through its own Column. Headings
at one inset and cards at another, on the same page.

The list and tree delegates right below it already use the shape that works —
a full-width delegate with the inset on the child — so the grid now does too.
The inset lives where the view has no opinion about it.

cc
2026-08-19 23:56:08 -06:00
vicrodh e1876c15f0 feat(qt): the artist page's radio disc goes live, with a start-up indicator
The disc was btnEnabled: false with a comment saying neither engine had a seam
on a Qt bridge. Both do now. ArtistPageView.slint:426-461 opens a two-row
dropdown — QBZ Radio (the local qbz-radio pool builder) and Qobuz Radio
(/radio/artist) — and that is what this restores. The smart arm already
shipped behind Discover's spotlight RADIO card and simply was not wired here;
the Qobuz arm is new (get_radio_artist + the same enrich_radio_tracks the album
radio uses, because its track objects are just as bare).

Both labels already exist in all eight catalogues, so no new msgid.

AND THE WAIT IS VISIBLE NOW. A radio is a fetch, an enrich and a queue write;
until the first track resolves nothing on screen moves, so the click read as
dead. QbzCircleAction gains the `loading` arm the reference already has
(CircleAction.slint:18/:77) and QbzHome.radioPending carries the KEY of the
radio being built — "album:<id>" or "artist:<id>" — so the Discover rail spins
only the station that was clicked instead of all six.

The spinner rides QbzShell.pulseMs, NOT a RotationAnimation. Qt Quick has no
partial redraws, so a continuous animator presents the whole window at display
rate (~1.2% GPU per present on the owner's hybrid laptop); a 60 Hz spin for the
seconds a radio takes is exactly the bill the pulse law refuses. 12 degrees per
~30 Hz tick, and the Connections is disabled unless the button is spinning and
on screen, so at rest it writes nothing. theme/QbzSpinner.qml still uses a
RotationAnimation and is deliberately not reused.

On the cards, `loading` also pins the hover disc up: it only exists on hover,
so it vanished the moment the pointer left after a click, which is what made
the click look swallowed.

A RadioGuard disarms the key in Drop, so a bad id, a network error and an empty
result all clear it. A disc spinning forever is worse than no indicator.

cc
2026-08-19 23:55:07 -06:00
vicrodh e816436fd0 feat(qt): remember where each page was scrolled, across back and forward
The port of the block Slint repeats in 27 views (NavState.restore-scope /
scroll-restore / report-scroll). A .slint file cannot hand a component a
reference to a Flickable, which is why the reference inlines it; QML can, so
controls/ScrollMemory.qml exists once and 31 containers mount it.

Two divergences from the reference, both forced by the same fact — tabs are not
history entries in this port:

1. THE SCOPE IS NAMED BY THE VIEW, not derived from the entry by a scope_for
   table. Slint can derive it because its entries carry the tab
   (Favorites { tab }); here an entry is a bare route id, so a derived scope
   would read "library" for all five Library tabs and pour the Albums grid's
   offset into whatever tab mounted. Letting the reporter name its own scope
   buys tab granularity for free, and the mismatch case degrades the right way:
   an unmatched scope restores NOTHING instead of restoring the wrong thing.

2. THE RESTORE RE-ASSERTS instead of firing once. A Qt item view resets
   contentY to 0 whenever its model is replaced, and several pages assign their
   model from a binding whose inputs arrive over the network after the mount —
   the album page rebuilds listCells from three deferred rails, so it hands its
   ListView a new array up to four times in its first seconds and snaps back to
   the top over a restore that already ran correctly. The offset is held and
   re-applied until a 2.5 s deadline, or until the user takes over (a wheel, a
   drag or a flick raises `moving`, and from then the position is theirs).

Diagnostics are off by default: QT_LOGGING_RULES="qbz.nav.scroll.info=true" for
the QML half, RUST_LOG=qbz=debug for the stamp/arm half.

cc
2026-08-19 23:54:46 -06:00
vicrodh 730ae6998e feat(qt): windowed View-all artwork, a real per-rail default, Play later, MyQBZ tabs
VIEW-ALL PAGES GOT THE LIBRARY > ALL TREATMENT, in both halves.

PlaylistBrowse windowed nothing: every card mounted, and a View-all of
playlists runs to hundreds, each a PlaylistCard carrying a four-tile collage.
AlbumCollection had solved that for the album pages and this one never got it.
The band is sampled on a timer rather than bound to contentY — a direct binding
re-evaluates every delegate on every scroll frame — and out-of-band cards keep
their footprint as bare Items, so the scroll geometry and the infinite-scroll
trigger never move.

Covers arrived in ONE batch: Rust downloaded every missing cover of the page and
then republished the whole document to attach the paths, so a page had no
artwork until it had all of it, and the republish rebuilt every delegate on
arrival. Both browse pages now ask for what is near the viewport and take the
answers one key at a time through the existing sidebarArtworkWindow ->
libraryArtworkReady seam. `attach_card_art` stays — it is a pure disk-cache
lookup, so anything already downloaded still renders on the first frame with no
request. The two now-dead republish helpers are gone with it.

The AlbumCollection change is ADDITIVE for its nine hosts: those that pass no
`flick` never report, the map stays empty and `artOf` falls through to the
`artPath` they already publish.

ITEMS PER CAROUSEL now has a real default instead of a lie. The first entry read
"All", which was wrong twice over: an "all" in Qobuz terms is what the View-all
page holds, and /discover/index hands each rail a different count anyway —
measured on a live response, new_releases 26, ideal_discography 26, playlists 20,
most_streamed 15, and qobuzissims / album_of_the_week / press_awards 10. No
single label could be honest about all of them, so the default became a real
uniform cap of ten and the entry says so. That is a behaviour change and not
only a label one: the rails that used to arrive at 26 now arrive at 10, and the
select is how a rail gets more. Ten therefore stops being a separate option
because it IS the first one, and the number comes from Rust so the label and the
cap cannot drift. The select also went 82 -> 124 wide: "Default (10)" elided to
"Defaul…" in both the closed control and the popup.

PLAY LATER on the album page's track rows. It was off because
`enqueue_album_track` had only two arms — "next" and "everything else appends" —
so "later" and "queue" both plain-appended and offering both would have been two
menu entries doing one thing. The third arm lands on the manual block's tail via
`add_track_later`, which is the whole distinction, and the QConnect route stops
collapsing "later" into "queue" (route_track_to_peer has had a real later arm
all along). Only then does the entry turn on.

MIXTAPES <-> COLLECTIONS as a tab bar, the Discover/Library pattern where the
tabs stand in for the page heading. They are separate ROUTES sharing one
component, so a tab click navigates rather than flipping a local property: the
sidebar highlight, the back stack and the `kind` Binding then agree on where the
user is, and the page transition is the one every route change gets.

Eight locales. Release build clean, offscreen smoke green, 421/421 and 216/216.

cc
2026-08-19 13:53:30 -06:00
vicrodh 81e172457f fix(qt): migrate playlist_meta, break a router binding loop, zebra the playlist
RECENTLY PLAYED PLAYLISTS STAYED EMPTY THROUGH EIGHT TRACKS, a restart and a
manual refresh — while the plays were sitting in the database the whole time.
Read off the live file rather than reasoned about: `playlist_play_events` held
3, 9 and 10 rows for three playlists, so the context edge was working perfectly;
`playlist_meta` was empty, and its `.schema` said why — no `covers`, no
`own_image`.

`covers` and `own_image` were added by inlining them into the CREATE. `CREATE
TABLE IF NOT EXISTS` does NOTHING when the table already exists, so anyone who
had run the previous build kept the six-column table, every upsert failed on
"no such column: covers", and the rail JOINs meta against events — so it
rendered its empty state with the evidence one table away. The failure was
invisible by construction: swallowed into a warn, and the UI's empty state is
also its correct state for a user who has played nothing.

A brand-new table is only new ONCE. The moment a build runs anywhere its schema
is legacy and every later column is a migration, so the pair moves to the same
idempotent ADD COLUMN the album history already uses, and the upsert's failure
becomes an error rather than a warn. Verified against a copy of the real
database: the columns land and all 22 events survive. A regression test builds
the exact pre-covers schema, records a play into it, migrates, and asserts the
upsert works and the old event still counts — it reproduces the bug without the
fix, and it also asserts a second `init_schema` is a no-op, since every launch
calls it.

The meta is written by `playlist_qt::load`, so the three playlists already in
the events table surface as soon as each is opened once.

BINDING LOOP IN THE ROUTER, and this one was self-inflicted: "QML Loader:
Binding loop detected for property source". `_stampRoute` runs inside the
`source` binding, and it read the last path from a `property string` and then
wrote it — a binding depending on a property it mutates. QML detects the cycle,
warns, and stops re-evaluating, which is a broken router and not merely a noisy
log. The holder becomes an object whose MEMBER is mutated: no change signal, so
the dependency is satisfied once and never fires again.

(The second warning on the same file, the `when` loop on the nav-flyout
`activeTab` Binding, is untouched by any of this work and predates it. Left
alone deliberately — it is a warning on a working feature, and rewriting that
Binding is its own change.)

ZEBRA on the playlist detail's track rows, like the local album page. TrackRow
already owns the stripe, so it is one property.

Release build clean, offscreen smoke green, 421/421 and 216/216.

cc
2026-08-19 09:01:32 -06:00
vicrodh 907d366d71 fix(qt): Library artwork loaded one row; add Refresh content to the configurator
LIBRARY ALL / ALBUMS LOADED EXACTLY ONE ROW OF COVERS and then nothing until
the user nudged the scrollbar. The grid and the list reported their artwork
window on contentY, model, width, visible and completion — but NOT on height,
and their height is gated on `visible` (`height: visible ? parent.height - 16 :
0`, the 2026-08-17 change that stops a hidden body from refilling). QML gives no
ordering between "the `visible` change handler runs" and "the `height` binding
that depends on `visible` re-evaluates", so when the handler wins the reporter
reads height 0 and computes `lastRow = ceil(0 / cellHeight) + 1 = 1` — a window
of exactly `cols` items. One row. Nothing fires again until a scroll, which is
why moving the scrollbar "fixed" it.

Playlists were unaffected and that asymmetry is the tell: PlaylistCollage
dispatches its own urls per delegate, independent of the window, while album
cells live off `artMap`, which only the window report fills. The control case is
in the same tree — LibraryAlbumsList, the playlists list and the Artists rail
all report on height and none of them has the defect. The two bodies that lack
the handler are exactly the two whose height is gated on visibility; `width` had
one because width always changed, `height` never did before the gate.

REFRESH CONTENT in the Discover configurator. The index is fetched once per
shell entry (`HOME_LOADED` latches and `reload_home` is never called again), so
a session shows the page it opened with — no new catalogue rows, and none of the
plays made since, because the recently-played rails are built from the local
history in that same pass. Everything else in that modal re-renders from the
cached candidates, which is precisely what cannot produce fresh ones. The
invokable already existed for the error-state retry; this is the door. The Reset
button's markup became a shared FooterButton so the pair cannot drift.

cc
2026-08-19 08:37:44 -06:00
vicrodh f0d753a751 fix(qt): fade on tab switches, playlist recents artwork, per-rail sizes, wheel
Four defects from the smoke of 26ceeab82.

TAB SWITCHES DID NOT FADE. The page fade hangs off the router's Loader
`source`, and a tab switch inside a view never touches it — so Discover's four
tabs, Library's and Local Library's cut hard while a route change faded, which
is the same event from where the user sits. `activeTab` is the one name every
tabbed view uses for this (the nav-flyout Binding already routes through it),
so one Connections in the router covers all of them; `ignoreUnknownSignals`
leaves the untabbed views alone. No watchdog and no opacity assignment there: a
tab body is built synchronously in the same turn, so `restart()` alone — which
sets the page to `from` — is the whole transition. The `running` guard keeps a
tab stamped right after a route change from restarting that route's fade.

RECENTLY PLAYED PLAYLISTS DREW PLACEHOLDERS. The rail published only
`artwork_url`, taken from the detail page's `cover_url` — and that field is
empty for every playlist WITHOUT a graphic of its own, which is most of them
and is exactly why the detail page falls back to a collage. A local playlist has
no Qobuz graphic at all, so it could never resolve one. The meta store now keeps
the member covers and an own-image flag beside the url, and the card gets both
arms it already knows how to draw: contain-fitted single graphic, or the mosaic.
All of it rides `art_url` and lets `attach_cached` fill the path —
`artwork_qt::cached_path` already classifies http, Plex and on-disk paths, so a
custom cover and a local file resolve through the same pass as a Qobuz url.

ITEMS PER CAROUSEL WAS ONE NUMBER FOR THE WHOLE PAGE. Tauri's was per rail
(`HomeSettingsModal.svelte`), and the global was a simplification that lost the
point of the feature: a 25-wide "New Releases" beside a 10-wide "Recently
Played" is why anyone opens it. Storage is now a row per section — absent means
the default, and setting a rail back to the default DELETES its row, so the
file only carries what was actually changed. The select moves into each row of
the configurator, and the cut moves into `order_by_prefs`, keyed by the PREF id:
`mostStreamed` resolves to a per-tab variant candidate, so the section's own id
is not always the id the user configured, and that loop is the only place both
are in hand.

OPEN OVERLAYS LET THE WHEEL THROUGH. A MouseArea consumes presses and NOT wheel
events, so with the configurator open the pointer still scrolled the page
underneath — over the panel it moved the panel's own list and the page behind it
at once. These overlays are plain Items rather than Popups, so nothing grabs for
them and each has to stop the wheel at its own surface: the configurator, the
genre popup, the playlist-category popup and the Local Library funnel.

Release build clean, offscreen smoke green, 421/421 and 215/215.

cc
2026-08-19 07:34:28 -06:00
vicrodh 26ceeab828 feat(qt): mixed playlists, page fade, category filter, per-context recents
Six parity fronts against the Slint/Tauri references, plus the applied-filters
tooltip the app never had.

MIXED PLAYLISTS — the bug. A mixed playlist is a QOBUZ playlist carrying local
and Plex rows through library.db's playlist_local_tracks / playlist_plex_tracks
sidecar tables. This port could WRITE those rows (the picker) and COUNT them
(the Playlist Manager badge), but playlist_qt::load built its rows exclusively
from the Qobuz API response, so a track added to a playlist never appeared on
the page it was added to. Two comments elsewhere claimed the merge already
happened; they were describing the reference. Ported literally:
read_sidecar_rows_blocking (healing + bulk Plex resolve) and interleave_rows
(absolute-slot claim, same-slot collisions all emit), merged in load, with the
merged queue adopted as the open-detail snapshot.

Routing had to split with it. local_playlist_qt::open_id() was the one
predicate for every action, and a mixed detail adopts that same snapshot — so
it now means "a local:<uuid> detail OR a mixed one", which is right for
play/shuffle/row-play and wrong for the writes. Remove and reorder route on the
new local_detail_open() instead; without that, removing a local row from a
Qobuz playlist wrote into the local-playlist repo, found nothing, and reported
success. Removal by source is a third arm: the Qobuz arm parses the display id
as a u64 playlist_track_id, and a local row's display id is a library.db rowid
in the same numeric space. Reorder is refused on a mixed detail for the same
collision, in Rust and in the view.

PAGE FADE. 300 ms OpacityAnimator on the mounted page, OutCubic, honouring
reduceMotion. Zero added latency: the router's Loader is synchronous, the UI
thread is frozen through the mount and no frame exists in which a fade-OUT
could be shown, so the page snaps transparent in the same turn as the rebuild
and only the reveal is animated. An Animator and not a NumberAnimation because
it runs on the render thread — measured 0.53 vs 0.11 of progress with the GUI
thread blocked — and not on the shared pulse because the pulse arrives on the
very thread the mount blocks.

The first cut faded a veil coloured from the pane, and that was wrong in a way
that only shows in the configuration the app actually runs in: AppShell paints
the pane surface-main@0.22 while the ambient background is on, so a veil at
full opacity covered 22% of the page and the fade read as a flicker. Fading the
page has no such failure mode and keeps the ambient art visible.

SPLASH COPY. The login screen was already 1:1 (18 msgids, verified by diff).
The splash was missing the legal disclaimer the reference pins to the bottom of
the screen, drew "QBZ" / "QOBUZ PLAYER" as bare literals (English in all eight
locales), and hardcoded the dark palette — black on the other 34 themes.

CATEGORY FILTER on the Home playlists rail. Slugs now travel per card and the
offered set comes from the same /discover/index response, so the filter is
client-side over the cached 40 with no extra request. The selection lives in
Rust because HomeView is destroyed on every navigation; the reference keeps its
own for the same reason. New trigger + popup, and a `leading` slot on
QbzSectionHeader to hang it off the title line.

APPLIED-FILTERS TOOLTIP. A third QbzTooltip mode taking [{group, values}],
below the control with an upward caret. Overflow is staged summary and never
scroll — the overlay is enabled:false by construction, so a scrollable tooltip
could not be scrolled. Wired where a filter is INVISIBLE (collapsed to a count
or a glyph): the genre chip in four hosts, the Home tags, the Local Library and
Purchases funnels, the Artist Scene genres.

RECENTS BY CONTEXT. QueueTrack already carried context_kind and exactly one
function threw it away: record_queue_track wrote both album histories on every
track start whatever the user had put on, so one 40-track playlist filled a
24-entry album rail with that playlist's contents. album_play_events gains an
additive context_kind column (the other frontend names its columns on insert,
so it writes '' and '' counts as an album — no history reinterpreted), plus a
new playlist_play_history.db and a "Recently Played Playlists" rail, default on.
A separate file rather than a field in recently_played.json, which is a
destructive round trip between frontends: serde drops what it does not know and
the next write puts the truncated object back.

ITEMS PER CAROUSEL, recovered from Tauri and never ported to Slint. It lives in
a NEW TABLE of discover_prefs.db, not in the prefs blob: to_json rebuilds the
object from the keys the running binary knows and save overwrites the whole
column, so a new key would survive only until the other build's next toggle.
Default is uncapped, i.e. today's behaviour.

Two DiscoverySectionId arms were added to the frozen Slint tree, obliged by the
shared enum's exhaustive matches — same two-line follow MostPlayedAlbums took.
Not verifiable here: compiling that crate pulls qbz-ui.

Also fixes two recommendations_qt tests that had been red since c02e7713d,
which turned the two Weekly rows into ordering slots that deliberately do not
self-hide while the assertions kept the pre-split behaviour. Verified by stash
that they fail without any of this change: the code was right, the tests stale.

Eight locales updated. Release build clean, offscreen smoke gate green,
qbz-qt 421/421 and qbz-app 215/215.

cc
2026-08-19 07:00:35 -06:00
vicrodh 047db8ea9f perf(qt): recycle the album page's track list, on a uniform-cell ListView
DID NOT DELIVER ITS GOAL. Read this before extending it: the wheel scroll on
a 189-track album is essentially unchanged. The page is correct and the
structure is better, but the theory that motivated the work is not supported.

What the work assumed: the ceiling was the `Repeater`, which has no windowing
and so built all 189 track blocks — each a Column with a disc-header Loader, a
work-header Loader (both gated on DATA, never on the viewport, so every act and
scene header in a Wagner box was alive) and the band-gated row. Roughly a
thousand structural items before counting anything visible.

What it is now: one ListView over a UNIFORM 10px cell tape. Each piece of
content owns a run of cells, its visual item lives in the first cell of the run
and paints over the inert ones — 50px row = 5 cells, 40px header = 4, rail =
29. Uniform cells are the point: measured in a standalone probe, a ListView
with variable delegates ESTIMATES contentHeight and ignores an explicit
override (5703 then 5396 against an exact 5400), which makes the scrollbar
thumb resize and skip as sizes are discovered. With uniform cells,
count * 10 is exact from the first frame, so the scrollbar the owner had just
called the best gesture on the page keeps its behaviour.

Falling out of the design, replacing machinery that was reverted a commit ago:
`cacheBuffer` incubates upcoming delegates asynchronously in idle time, so a
heavy rail is built before it is visible without a hand-rolled band, a settle
Timer, or an unload grace — and without the "reach the bottom, then wait" that
made the owner reject that approach.

Two correctness items that came with it:
  * `header` is a ListView property. The page's own `header` had to become
    `albumHeader` or every `header.x` binding inside the view would silently
    resolve against the view's header instead. One handler was missed in the
    rename and QML refused to create the component at all — the whole page
    rendered black, and no static gate caught it because the failure happens at
    instantiation.
  * `recycleActive` on the shared TrackRow, default true, gates the row's
    Connections. Without it a pooled row keeps listening and consumes a cache
    or favourite settle signal meant for a different track. Every other host
    is unaffected by the default.

WHAT THIS RESULT MEANS, for whoever picks it up: delegate count and
construction cost are NOT what makes this page feel heavy. Removing ~950
structural items changed nothing the owner could feel, which points at
per-frame cost instead — consistent with his own observation that the page is
sluggish ALWAYS, not only while it loads, and with the documented finding that
this shell's bill is full-window presents rather than scene work. Do not
re-attempt a structural rewrite here on intuition. Take the QSG_RENDER_TIMING
split (polish/sync vs render) on this exact album first; the earlier reference
scene measured polish=0ms, render=2ms, swap=12-24ms.

Design and probes came from an independent review; the rebase onto the current
tree, the black-screen fix and the API verification are mine.

cc
2026-08-18 23:28:25 -06:00
vicrodh 3fdccae22e Revert "perf(qt): the album page's rails exist only near the viewport, and never build mid-scroll"
This reverts commit 5b99a6698.

The gating worked and the numbers were real — the scrollbar drag went from the
worst gesture on the page to the best — but it bought that with a delay the
owner will not take: once you reach the bottom, the three rails now take a
visible moment to appear, which never used to happen. The build has to wait for
the flick to come to rest (that wait is what fixed the wheel-scroll spike the
gating itself introduced), so "arrive at the bottom, then wait" is inherent to
this design, not a tuning mistake.

Reverted to a known-good baseline rather than tuned, because the replacement
makes it moot: converting the page to a ListView puts the rails in `footer:`,
which the view instantiates as it approaches — near-viewport building without a
hand-rolled band, a settle timer, or an unload grace.

Kept in the history rather than dropped: it is what established that the rails
were fully built on mount whether or not anyone scrolled to them, and the
"builds synchronously in one frame, on the GUI thread" lesson is what the
ListView work has to respect too.

cc
2026-08-18 22:18:44 -06:00
vicrodh 313a7e7e4e fix(qt): the local album page gets its zebra, across the whole row
The shared TrackRow has had a `zebra` flag all along, off by default, and the
Qobuz album page turns it on. The local one never did — and turning it on at
the call site would not have been enough either, because LocalTrackRow wraps
the shared row without forwarding the flag.

Forwarding it is still not the fix. TrackRow tints its own background
rectangle, which is `parent.width` wide, and this wrapper hands the shared row
`root.width - 26 - 46`: a 26px gutter for the source glyph and 46px for the
context menu the wrapper draws itself. A stripe painted from in there stops
72px short and leaves both controls outside it — which is what the smoke
caught. The stripe is therefore painted by the wrapper, full width, declared
before the shared row so it lands underneath and takes no pointer events.
Same colour literal and same parity rule as rows/TrackRow.qml, so a local list
and a Qobuz list stripe identically.

cc
2026-08-18 22:15:33 -06:00
vicrodh 5b99a6698e perf(qt): the album page's rails exist only near the viewport, and never build mid-scroll
The three SectionRails at the foot of the album page were gated on `visible:`
alone, and in QML `visible: false` stops an item PAINTING, never building. With
data present all three were fully constructed the moment the page mounted —
three horizontal ListViews of AlbumCards, every cover a RoundedImage with two
render targets — whether or not the user ever scrolled down to them. On a long
album nobody reaches the bottom of, that is pure cost, and it sits in the SAME
Flickable as the track list, so those layers are in the scene for every frame
the list scrolls.

Each rail is now a fixed-size `RailSlot` with the real rail behind a
`Loader { active: inBand }` — the shape `rowSlot` in this file already uses.
Three things this had to get right:

  * The slot reserves 286px whether or not it is built (28 header + 12 spacing
    + 246 card band, the figure RailSkeleton already stands in with). A slot
    sized to its Loader would change the page length as rails build and slide
    the content under the user mid-scroll.
  * The band reads the slot's OWN `y`, which the Column assigns from preceding
    siblings only. The variant measured against a parent-derived height is a
    dependency cycle; it cost a day on 2026-08-18, because QML breaks the loop
    silently and every slot then reads as in-band.
  * An inline `component` does not share the enclosing document's id scope, so
    `page` / `pageFlick` / `root` are not resolvable from inside RailSlot. The
    geometry and the cover map are handed in as properties instead. Left as it
    was, the failure would have been silent: a band evaluated against zeroes.

Two follow-ups from the owner smoke, both about WHEN the Loader flips:

  * UNLOAD IS DELAYED 600ms. This page grows in stages (primary document, then
    deferred rows), and while the list is missing the page is short enough to
    put these rails inside the band. They began building, the rows landed, the
    page grew by thousands of pixels and the Loader tore them down again —
    and since a ListView creates delegates through incubation, tearing down
    mid-flight is exactly the "Object or context destroyed during incubation"
    warning that appeared three times, once per rail, on every album open.
  * BUILD WAITS FOR REST. A Loader creates its content synchronously, in one
    frame, on the GUI thread. Building the instant a rail crossed into the band
    put that spike inside a wheel scroll — measured by the owner as the wheel
    getting worse exactly as the scrollbar got much better, which fits: a drag
    ends before the spike lands, a wheel scroll does not. Creation now waits
    for `flickY` to stop ticking. That signal works for the wheel and the
    scrollbar alike, unlike `Flickable.moving`, which a scrollbar writing
    contentY directly does not necessarily raise. Already-live rails stay live:
    this gates the build, never the keep.

cc
2026-08-18 22:15:24 -06:00
vicrodh 77e9feccff feat(qt): album header — 260px cover, no divider rule, a gradient that lands mid-toolbar
Four owner-requested changes to the Qobuz album page, validated by smoke.

1. THE DIVIDER RULE goes invisible rather than away. The gradient band sizes
   itself off that item's `y` and the whole column below is positioned after
   it, so deleting the item would move the page; only the paint was unwanted.

2. COVER 224 -> 260. Now one constant: the literal was repeated at five sites
   — the real header, its skeleton twin, and the two text columns that measure
   `parent.width - 224 - 32`. Changing only the header would leave the
   skeleton at 224 and make the page jump 36px when the real one replaces it.
   The header Row has no explicit height, so it grows on its own.

   The URL tier is unchanged (`best()`, per the 2026-08-16 ruling that no
   existing surface is re-tiered DOWN); what decodes is RoundedImage's scaled
   derivative at the drawn size, so 260 over 224 is ~35% of a small image.

3. THE ATMOSPHERE REACHES MID-TOOLBAR — the 8px spacer below the divider plus
   half the 52px toolbar band — so it dies across the quality chip and the
   search box instead of stopping at the divider. A named constant rather than
   a `mapToItem` chain: that chain crosses three nested containers and goes
   stale when an ancestor moves without notifying.

4. THE FALLOFF IS PROGRESSIVE. The tint held FULL strength to 0.82 and died
   inside the last 18%, drawing a visible seam — and extending the band made
   it worse, not better, because the falloff is a FRACTION of the height: the
   solid part grew while the fade stayed as short. The page-surface overlay
   underneath started at 0.82 too, putting a second seam on the same line.
   Both now decay over the bottom ~60% on an ease-out curve, stepped through
   explicit alphas because a GradientStop interpolates linearly between the
   two colours it is given.

cc
2026-08-18 20:25:36 -06:00
vicrodh c02e7713d9 perf(qt): stop republishing the Recommendations document for artwork
Covers that resolved after the document was published forced a second
`publish_snapshot`, and a republish hands QML a brand-new array:
`QQuickItemView::setModel()` then resets each rail's scroll offset and tears
down its QQmlDelegateModel. So every landing batch rebuilt all nine rails'
delegates, which is what a screen capture of a cold Recommendations load
shows — the rows visibly reassembling while covers trickle in, filling out of
order both between rows and within a row.

The fix is the pattern this port already applies twice: covers travel as a
url-keyed PATCH and the document is left alone. `foryou_qt::emit_foryou_art`
is the precedent for the For You rails, and `myqbz_bridge` cites it verbatim
for MyQBZ; the reco rails were the remaining holdout.

The download path is deliberately untouched. This changes only how a resolved
path is ANNOUNCED, never what is fetched or cached, so every other consumer of
the shared image cache — the now-playing bar, the queue, the `recent` rails —
sees exactly what it saw before.

Two traps this had to close, both already paid for once on the For You side:

  * `sectionArtOf()` falls back to `item.artPath`. `recoArt` only ever holds
    Recommendations urls, so for a Home / Editor's Picks / For You card the
    lookup misses and the binding returns what it always returned. No surface
    that reads a baked `artPath` can lose its cover to this — by construction,
    not by care. The pinned rail, fed by its own store, is untouched.
  * `anyItemArtPending` now consults the map. A patched cover never gets its
    `artPath` back through a republish, so the bare "artUrl set and artPath
    empty" predicate would be true forever and pin the 900ms skeleton pulse
    Timer on.

`refreshRecoArt()` on mount is the third: HomeView is destroyed on every
navigation while this document is published once per session, so a fresh mount
must be re-handed what already resolved or the covers come back blank.

Weekly's two rails still republish their own narrower property; their blast
radius is two rails, not nine, and widening this change was not worth it.

Verified by owner smoke: the three checks (nothing else lost its covers, the
rails stop reassembling, covers survive navigating away and back) all pass.

cc
2026-08-18 20:25:22 -06:00
vicrodh 101d0e25d4 perf(qt): one rebuild per query in the local grid, and reveal covers in order
Two changes to the local albums grid, both BUILT BUT UNSMOKED — Local Library
is best-effort for the next release, so this is committed to preserve it
rather than because it was validated.

1. ONE REBUILD PER QUERY. `rows` and `groups` are two bindings over one query:
   the host derives `albumsVisible` from the search box and `albumsGrouped`
   FROM `albumsVisible` (LocalLibraryView.qml:378-380). With a handler each,
   a single keystroke rebuilt twice, and the first of the two was WRONG as
   well as wasted — it chunked the new rows against the previous groups.
   Turning grouping off did not save it either, because `groupRows` returns a
   fresh `[]` every time and a new array is still a change. Coalesced onto a
   zero-interval Timer: one rebuild per event-loop turn, reading both new
   values. `Component.onCompleted` stays synchronous so a mount does not show
   a frame of empty grid.

   `[coltiming]` logs every rebuild with its cost, so a smoke run can falsify
   the coalescing: one line per keystroke means it holds, two means it does
   not. Timed around the work, never from a deferred callback.

2. ORDERED COVER REVEAL. The cold-thumbnail pool starts work in window order
   but finishes out of order, since decode cost varies per cover, so covers
   appeared scattered across the grid. Ordering the emission in Rust would
   have made it worse: one slow decode at index 3 would hold 4..N behind it,
   adding latency instead of hiding it. Instead arrivals are applied behind a
   front that walks the window at a fixed rate; a cover landing behind the
   front is applied at once. The front advances every tick unconditionally,
   which is what makes a stall impossible, and a key with no ordinal is
   released immediately.

Note for whoever picks this up: this reveal covers the LOCAL path only. The
uneven fill visible in ordinary navigation is HomeView's For You rails, which
take a different route (`forYouArt` via `onForyouArtReady`).

cc
2026-08-18 19:15:06 -06:00
vicrodh ed081cac6b fix(qt): put the local albums scrollbar and A-Z strip on the real edge
LocalAlbumsTab pads its content 32px on the right, and both the scrollbar and
the jump strip lived inside that padding — so the bar sat 32px from the
window edge (52 with the strip up) while LibraryView.qml:1281 puts the same
control at 4, or 34 to clear its strip. Side by side the local grid's bar
reads as floating away from the edge.

The collection now takes two measurements, both from the WINDOW's right edge:
`scrollBarInset` (where the bar should land) and `hostRightInset` (how far
the component's own edge already is from it). The bar's margin is their
difference, which goes negative and overhangs — safe, because the component
root is a plain Item; the `clip: true` in that file is on the ListView, a
sibling. Both default to 0, so LocalArtistsTab and LocalFoldersTab, which
have not opted in, are untouched.

The A-Z strip moves out to 12 from the window edge, matching
LibraryView.qml:1269.

cc
2026-08-18 18:41:28 -06:00
vicrodh c0fe8a80d3 fix(qt): silence the TypeError flood the constant-cell grid introduced
Regression from the previous commit's first fix. Pinning the inner Repeater
to `root.cols` is what made recycling free, but it also means the tail slots
of a partly-filled row are now real, live cells with no album behind them.
The delegate anticipated that — `modelData` resolves to null and the cell
sets `visible: false` — and that is not enough: in QML `visible: false` stops
an item PAINTING, it does not stop its bindings EVALUATING. Every
`cardCell.modelData.id`, `.title`, `.artKey` on an empty slot therefore threw
once per evaluation, which during a scroll is a continuous log flood (the
same ten line numbers, over and over, seen in a smoke run).

`modelData` keeps its meaning — "is this slot filled?" — so `visible` still
works. The bindings now read `cardCell.slot`, which is the same object when
the slot is filled and a frozen all-empty object when it is not.
`artWanted("")` is false and `artPathOf("")` is "", so an empty slot stays
silent through the skeleton's probe arm too.

Deliberately NOT a Loader gated on the data: `active` would flip every time a
full row recycled into a partial one, rebuilding the AlbumCard — precisely
the construction churn the constant cell count exists to remove.

cc
2026-08-18 18:41:17 -06:00
vicrodh bd9aec1440 perf(qt): make the local albums grid actually recycle, and stop it asking
for the whole library

The owner's report is precise and is what this targets: the grid OPENS
fine; scroll, scrollbar drag and search are what feel sluggish, and "the
first two keystrokes hurt" — the ones where the filter still matches
hundreds. That shape is a model swap, not a slow filter.

UNSMOKED. Committed to save progress; no binary matches this tree.

1. FIXED CELL COUNT. `reuseItems` was already on the ListView and bought
   nothing, because the pool recycles the row SHELL while the inner
   `Repeater { model: modelData.items }` got a new array on every recycle
   and rebuilt its AlbumCards anyway. The card is where the cost is: ~29
   items, a RoundedImage with TWO render targets (its own layer plus a
   separate mask layer), image probes, a skeleton. The shell was reused
   and the expensive part was not. The Repeater now runs over `root.cols`
   — a constant — so cells survive recycling and a scrolled or refiltered
   row only reassigns `item`.

2. THE HEADER WINDOW BUG. `loIdx` fell back to 0 whenever the first
   visible entry was a group header, because headers carried no `base`.
   In grouped mode, scrolling with a header at the top of the viewport
   asked `queueWindowReport` for artwork from album 0 through the current
   letter — hundreds of covers dispatched and later evicted, per scroll.
   Headers now carry the flat index their group starts at.

3. SEARCH DEBOUNCE on the albums box, which the Tracks box in the same
   file already had. `albumsSearch` is not a query, it is the filter
   input: writing it per keystroke refilters 1267 albums, rebuilds the
   entry list and hands the ListView a new model, tearing down every
   delegate. Note the tradeoff — this ADDS 200ms before any work, so the
   box may feel more deliberate even as it stutters less.

Also here, from the album pages (lower priority per the owner — their
cost is paid once and the view is fine in use afterwards): the disc
header, which carried a CardMenu per TRACK, is Loader-gated; a genuinely
quadratic multi-disc scan in LocalAlbumView is hoisted out of the
per-row call; and the track rows are windowed. That windowing was
measured broken twice (a band computed against its own parent's derived
height — a dependency cycle) and the fix is unverified.

Credit where due: 1 and 2 came out of an independent review that also
judged the previous round's lazy menus and `reuseItems` "mostly beside
the main point". That is a fair call.

cc
2026-08-18 17:42:30 -06:00
vicrodh 47a7641fc2 fix(qt): bound the queue panels, and make the gate catch what it missed
Follow-up to 66ba12bd5, which fixed the coverflow but left two of its
neighbours and a gate that could not see either of them.

QueueTabsPanel built one ImmQueueRow per queue track when opened —
including every collapsed 0-height history slot, which on the reported
session was 1162 of 1935. The slot stays (its height is what makes the
collapsed-history arithmetic work); the row inside is now built only
within a viewport of the visible band.

SuggestionsPanel and AppShell's QueuePanel move behind Loaders. The
queue panel was never the freeze — its rows are paginated at 40 in
Rust — but a closed panel should not be constructed, and the audit
cannot know about a cap that lives on the other side of the bridge.
Gating it also let SuggestionsPanel drop the onVisibleChanged half of
its load hook: mounting IS becoming visible now.

The audit is the real content of this commit. Written narrow — only a
model fed by unbounded user data counts, because the wide rule reports
145 sites and a gate that noisy gets switched off in a day — it then
reported the pre-fix tree CLEAN. A gate that cannot catch the bug it
was written for is worth nothing, so it was tested against that tree
and fixed on two counts:

  - CROSS-FILE. The `visible:` sat in ImmersiveView.qml while the two
    Repeaters over the whole queue lived in CoverflowPanel.qml. There
    is now a transitive index: a component is heavy if its own file has
    an unbounded view or if it mounts something that does.
  - MULTI-LINE. The coverflow's gate spans two lines, so a first-line
    read saw `QbzShaderScene.scene === 0`, matched no known gate, and
    skipped it.

With both, it finds all five mounts on the pre-fix tree, including the
two that froze the app. Known gates also grew past tab predicates: the
coverflow was keyed on QbzImmersive.mode.

Verified on a copy of the real session state with the 1935-row queue
restored: launches to a painted Discover, idle at 1.0% CPU.

cc
2026-08-18 07:48:56 -06:00
vicrodh 0ed9db2f3f fix(qt): stop the Weekly rows rebuilding the whole Recommendations tab
Reported as "it loads, then it flashes and loads again", and only on
that tab. Measured: the cached blob paints at t+0 and the two Weekly
rows land at t+0.9s — and that is with BOTH of their per-week caches
hitting, so the delay is ListenBrainz's playlist listing, not the
tracks. Their arrival called publish_snapshot, which republishes the
document, which hands QML a brand-new array; QQuickItemView::setModel()
then tears down every rail's QQmlDelegateModel and rebuilds it. Nine
rails destroyed and rebuilt to deliver two, a second after the tab had
already settled.

Not the artwork, which was the obvious suspect: the same run logged
"0 artwork misses".

Split them out the way HomeView already splits pinned / radio /
spotlight, for the same reason and with the same shape: the document
carries an ordering slot, the rows ride reco_weekly_json, and rebinding
that re-creates only those two delegates. Every other rail's sectionData
resolves to the same modelData reference, so a Weekly landing
re-evaluates nine bindings and rebuilds two.

The slots are emitted unconditionally (a new `slot()` helper) rather
than self-hiding on emptiness like `section()` does — a slot that
vanished while empty and reappeared when filled would change the
document, which is the republish being avoided. QML hides an empty one
instead, on the gate the other out-of-document rails already use.

Weekly covers are attached in the same split, so a late cover
republishes that property rather than the document: two rails, not
nine.

cc
2026-08-18 07:25:37 -06:00
vicrodh 19836547d9 feat(qt): give Recommendations its cache window and Refresh now
The gear was dead on that tab and the cache window was unreachable, so
whatever hours value happened to be in the shared prefs was permanent.
It reads 24h on this account; the reference offers 24/36/48/72 and
defaults to 48.

Only the WRITER was missing. `reco_cache_ttl_secs()` already read
`reco_cache_ttl_hours` from the shared per-user discover prefs, and
`refresh()` was already written — and carrying `#[allow(dead_code)]`
because nothing called it.

TTL_HOURS is the reference's table verbatim (discover_prefs.rs:100).
That matters because the value lands in the file BOTH builds read: if
the two disagree on the index mapping, a window chosen in one reads
back as a different one in the other. The QML option order is the other
half of the same contract, noted at both ends.

The setter republishes the RESOLVED index rather than the one it was
handed, so a failed write (no per-user store) snaps the select back to
what is actually stored instead of showing a window nobody saved. The
index is seeded at shell entry next to publish_settings(), the first
point where the per-user directory is known — without it the select
would open on the store's 48h default and misreport anyone who chose
otherwise.

The modal now has two modes on the same six blocks the reference gates
(DiscoverConfigModal.slint:187/213/221/250/261/326): section tabs keep
the list, banner, count and reset footer; Recommendations hides those
and shows the explainer, the window select and Refresh now. Its
empty-state line is hidden there too — DiscoveryTab has no
"recommendations" arm, so an empty row list is by design and "No
sections to configure yet" would be a permanent lie.

All seven strings already existed translated in all eight catalogs.

Two comments removed on the way: both claimed the external reco engine
was "not ported" and justified the disabled gear with it. It has been
ported for a long time (recommendations_qt.rs, 745 lines) — the fossil
was the only thing still keeping the setting out of reach.

cc
2026-08-18 07:25:37 -06:00
vicrodh aa2f0362d9 perf(qt): stop Library building the body it is not showing
The grid and the list are siblings, both anchored to fill the content
area, and both bound to `visibleRows` — and `visible: false` stops a
QQuickItemView from painting, not from refilling. Measured with a
per-view creation counter: on Albums the grid built 51 delegates and
the hidden list built 47 beside it; on Tracks the list built 47 and the
hidden GRID built 51, the expensive direction since a FeedGridCell
carries a cover. A mount went 368ms -> 216ms, to-idle 727ms -> 441ms.

The predicates above them already claimed this ("one predicate per
body, so no two can mount at once"); they only ever governed painting.

Gated by collapsing the height rather than by swapping the model: this
file spends a paragraph on why handing `model` a new value is harmful
(QQuickItemView::setModel resets the scroll offset and rebuilds every
delegate — the "a heart click in All throws me back to the top" bug),
and the height gate leaves `model` untouched.

Also: the derive and the feed parse are now timed under the shared
qbz.nav.timing category, deferred through Qt.callLater. The defer is
required, not tidiness — `visibleRows` is evaluated during creation,
and a LoggingCategory used before the component completes never gets
its defaultLogLevel applied, which Qt warns about and which left the
logging ON for every user. The parse log was previously a bare
console.log doing exactly that.

Measured for the record: the derive is NOT the cost. Over a 354-item
feed it runs in 0-13ms, so the O(n log n) toLowerCase in its sort
comparator is a real but currently theoretical problem.

cc
2026-08-18 07:25:37 -06:00
vicrodh a4c29c796c perf(qt): build the tab that is showing, not all of them
Entering Discover froze the UI thread for 1.52s — not slow, frozen:
zero pixels changing anywhere in the window — where the Slint build
painted the same page, artwork included, in a single frame. Measured
frame by frame from a screen recording, with the click located at the
moment the nav flyout disappears.

`visible: false` hides an item; it does not stop QML from building it.
HomeView declared its four Discover tabs as sibling Columns gated only
on `visible:`, so every mount instantiated all four and 19 of its 28
section rails belonged to tabs nobody was looking at. Gating each body
on a Loader's `active:` cut a Home mount from 426-512ms to 182-190ms,
and the tab block itself from 364-444ms to 134-140ms.

Synchronous, deliberately: incubation is time-sliced, so `asynchronous`
spreads the same work over more frames instead of removing it.

Three more of the same class, found by auditing for it:
  - SlimGrid's delegate Loader had no `active:`, so it built a full
    card for the items past `total` and then hid them.
  - LocalLibraryView mounted all four tab bodies, the Tracks one being
    the 16K-row view.
  - AlbumInfoModal built a credits row per track of the album even when
    the Description tab was showing.

ContentRouter's header claimed the fix was to keep views alive across
navigation. It is not, and the references say so: Slint destroys its
view tree with `if` (AppShell.slint:426) and Tauri removes it from the
DOM (+page.svelte:6286), and Tauri even refetches from the network on
mount while still transitioning instantly. Neither gets its speed from
caching the view — both keep the mount proportional to one viewport.
The rule is the SIZE of a mount, not its lifetime. Paragraph rewritten
to say that.

cc
2026-08-17 17:49:11 -06:00
vicrodh e779b6ec1e fix(qt): a pulled track's menu offers nothing that leads nowhere
Smoke found the row rendering correctly and the menu still offering four
entries that cannot work on it.

Add to mixtape and Add to playlist are refused, in both row implementations.
The precedent was already there -- `hasPlaylistAddSeam` excluded a broken local
ref for the same reason -- this is the same idea with a different cause. Gated
on `pulled` rather than `pulledDead`, so a downloaded copy is refused too:
what a playlist or mixtape stores is the Qobuz catalog id, which is dead on
every other device, every other surface and for anyone the list is shared with.
The local copy playing here does not make the row safe to seed elsewhere.

Both share links go too. Qobuz's page for a withdrawn track is gone and
Song.link resolves through it, so each one rendered and led nowhere. Track info
as well: it needs the catalog record the pull took away.

That empties the menu on a surface that does not offer the repair -- an album
page, search results -- so the row menu no longer opens when its model comes
back empty. An empty popup reads as a broken control rather than as "there is
nothing to do with this row". The ArtistView fork keeps its go-to entries and
can never reach that state.

cc
2026-08-17 15:37:12 -06:00
vicrodh 7780efa5db feat(qt): mark tracks Qobuz pulled, and keep them out of the queue
Qobuz withdraws tracks: sometimes a recording, sometimes only a quality tier,
sometimes it republishes the same recording under a new album id. The row keeps
appearing and simply cannot play. Until now the user found out by clicking it.

The app already knew and threw the answer away: eight builders hardcoded
`streamable: true`, so the API's own flag never reached a row model. The
reactive half was already here and stays -- a terminal failure still toasts and
skips, bounded at five consecutive, with the 403 back-off kept separate so a
403 storm cannot burn five good tracks.

Detection has two clauses. The API's `streamable: false`, and a session-only
memory of tracks that died terminally under the player this run: /album/get is
honest, but plenty of rows only fail at the stream-url step, and that memory is
what stops the queue re-offering them. Session-only on purpose -- the reference
kept the equivalent set in localStorage, never expired it and never revalidated
it, so a track Qobuz restored stayed dead forever.

Dead rows are dimmed, get an alert glyph and a tooltip, lose click, drag,
favourite and download, and STAY visible and right-clickable: hiding them would
defeat the point and remove the only route to a replacement. Qobuz's own player
does exactly this, and the pulled track carries displayable:false while still
being rendered -- that flag is not a hide instruction.

A downloaded copy is exempt everywhere. The offline tier resolves before any
availability question, so a pulled track already on disk plays fine; dropping it
from the queue would take away something the user downloaded, and it would bite
hardest offline. Those rows say they are playing the local copy and keep their
play affordance.

Two seams filter, not one, and both had to learn the surviving anchor: every
caller read `first_id` from the UNFILTERED list, so the seam dropped that row
and the app then asked the player for the id it had just discarded -- silence,
no toast. That was already reachable today through the artist blacklist. The
seams now return the surviving start and its id.

Two id bugs surfaced on the way and are fixed here. A playlist row's
`playlist_track_id` was filled with the CATALOG id; they are different numbers
for the same row, one naming the recording and the other its slot in that
playlist, and Qobuz's delete and reposition verbs both take the membership id --
so "remove from playlist" was addressing a row that does not exist. And the For
You rows were built with `..default()`, claiming availability while the queue
built from the same track read the truth.

Catalogs: the two strings this needed already existed in all seven translated
locales and are reused; the skipped-tracks toast is a plural pair, and the
replacement feature's strings ride along here since they share the files.

cc
2026-08-17 14:41:26 -06:00
vicrodh 5d1448b23e feat(qt): pin the award page's controls in a nav bar
Search, shuffle and the award picker are one right-aligned cluster in a
pinned 44px bar now, given the ArtistView jump-nav treatment: its own fill,
a 1px bottom hairline, the page's 32px rhythm, and a slot in the flow that
reserves its height so the hero does not jump when the bar is lifted out.

Order inside the cluster is left-to-right from "narrow this" to "leave
here": the search and the shuffle act on the page you are on, the picker
takes you off it.

Carries the rounded-corner rule this codebase has hit twice already
(ArtistView.qml:2795, the Discover full-bleed toolbar): pinned at the pane's
top edge the bar's square corners poke out past the shell's rounded bezel,
so the top corners round — but only WHILE it is at the top, driven off the
live y. Mid-page the bar is surrounded by content and a notch there is worse
than the square corner it fixes.

The picker still tracks the OPEN award: `currentIndex` is the document's
`catalogIndex`, so navigating to another award moves the selection with you
instead of stranding it on the one you came from.

cc
2026-08-16 20:12:45 -06:00
vicrodh 2d33a4fdfb feat(qt): search, load more and random on the award landing page
Three controls so the landing is usable without bouncing through "See all".

Search sits in the section header and shares the LISTING's query — one
award, one filter — so what you type here is still in force behind See all.
Client-side over the loaded set, like the listing and like the reference.

Load more is a BUTTON, not infinite scroll. The listing sub-view owns the
scroll-driven paging; this page has the "Other awards" rail under the grid,
and auto-loading would push that rail out of reach forever. Suppressed while
a query is active, for the listing's reason: paging in rows the filter then
hides is work with no visible result.

That button needed the preview cap gone. The landing document published
`take(PREVIEW_PAGE_SIZE)`, so "load more" would have fetched rows the view
threw away. The first fetch still asks for one preview page, so the first
paint costs what it did before; the cap is now only on the REQUEST, not on
what the document carries.

Random plays one album out of the LOADED set (the LibraryToolbar precedent:
pick a visible row, `QbzPlayer.playAlbum`). Not the whole award — the rest
is not here to pick from, and reaching for it would put a blocking fetch
behind a button that should feel instant.

Every mutation republishes BOTH documents now: they share one accumulating
album list, so a page loaded or a query typed on either side is visible on
the other.

No new msgids — "Search albums & tracks…", "Load more" and "Loading…" are
all in the eight catalogs already.

cc
2026-08-16 19:54:15 -06:00
vicrodh 1f636679d5 fix(qt): "Play all next" enqueues the artist instead of replacing the queue
The artist ⋯ menu offers "Play all next", "Add all to queue" and "Shuffle
all". The first was wired to `playArtistTop(false)` — which the bridge's own
doc calls "Play all": it REPLACES the queue and starts playing. There is no
plain "Play all" row in that menu, so there was no way to get the intended
behaviour, and asking to queue an artist next wiped whatever was queued.

The invokable takes a mode now and both rows route through the shared
insertion funnel: "next" inserts at the cursor, "queue" appends. That is
what the reference does (`enqueue_artist_top_selected(.., next: true)`) and
what `playback_qt::enqueue_artist_top_mode` was written for — it had no
caller at all, which is how the miswiring survived.

cc
2026-08-16 18:56:38 -06:00
vicrodh dc2496e5c0 feat(qt): award pages, reachable from the album sidebar and from each other
Ports the Slint/Tauri award pair: the landing (gold laurel hero, magazine
line, follow heart, "Acclaimed Releases" with its count and See All, the
preview grid and the "Other awards" rail) and the paginated listing with
its client-side search. Routes "award" and "awardalbums", the label pair's
shape — one controller for both, since they share the hero, the follow
state and the identity.

The three rules from the Tauri review are in the module header because they
are the ones a re-implementation gets wrong: the grid is ALWAYS
/award/getAlbums (/award/page is user-scoped and may omit releases, so it
feeds the hero and nothing else); the favorite split is plural-read,
singular-write, because the backend derives `award_ids` from the write
kind; and getAlbums has no has_more, its `total` is a hint, so the only
sound predicate is `total > loaded`.

The album sidebar's AWARDS cards navigate now — with an id directly, and by
NAME through the resolver when Qobuz omits it, which it does. They were
also reading `album.awards` when the field lives on `album.header`, so the
block had rendered EMPTY for every album since it was written: an empty
Repeater draws nothing and reports nothing, and the sidebar's own gate
counted the same empty list. The LABEL card beside it had a "no label view
yet" note and no handler, years after the label view landed.

Beyond the reference: an all-awards dropdown pinned to the page's top-right,
so any award is reachable without first finding an album that won it. It
costs nothing new — the /award/explore crawl already existed to resolve
names to ids.

The award icon was lucide's MICROPHONE under the wrong filename. Search had
routed around it with `crown` and left a note; kiosk was missed and drew a
mic for "Most popular". The asset is the laurel the other two frontends use,
and kiosk now asks for the crown it wanted.

cc
2026-08-16 18:56:20 -06:00
vicrodh 41c1b50d61 feat(qt): offline cache manager, and stamp the album identity on cached tracks
The last missing Settings surface: the OFFLINE CACHE group (Open manager /
Open folder / Clear all) and the manager view behind it — stats bar with
the GB limit, sort and failed-only toolbar, A-Z artist rail, album+track
rows with per-row re-download and remove. The engine was already here; what
was missing were four actions (remove_album, redownload_track, open_folder,
clear_all), the rollup and the view.

Two bugs the owner's smoke exposed, both older than this view:

ALBUM IDENTITY WAS BEING LOST ON EVERY ALBUM DOWNLOAD. A Track inside an
/album/get payload carries no nested album object, and `track_cache_info`
read exactly that, so `cache_album` wrote `album = NULL, album_id = NULL`
for every track it queued. Measured on a real index: 34 of 46 rows, three
complete albums. Not cosmetic — `album_id` is the key `remove_album`,
`redownload_album` and the downloaded-album registry look rows up by, so
those albums could not be removed, refreshed or recognised as downloaded.
The album document now stamps id and title onto every track that lacks its
own. The reference has the identical bug.

AND THE ROLLUP MIXED ARTISTS. Every row without an album_id collapsed into
one "__singles__" bucket titled from the first track and credited to its
artist, so three albums by three artists rendered as ONE album header while
two of the artists vanished from the rail. The key is a ladder now: album
id, else (artist, title), else a per-ARTIST singles bucket — two artists
can no longer meet in one group even with the broken data. Rows already on
disk recover their title from library.db, which does know it, so an
existing cache reads correctly without re-downloading.

Deltas from the reference, both because Qt is not Slint: covers are paths
(slint::Image is not Send, which is why it pre-decodes; Qt has no such
constraint) and selection is QML-local, this port's convention, which keeps
the document a pure function of the DB so a finishing download cannot fight
the user's checkboxes.

Clear-all confirms first — the reference fires straight from the glyph, and
undoing this one means re-downloading the whole cache.

cc
2026-08-16 18:54:16 -06:00
vicrodh 9899ad6b09 feat(qt): open the playlist importer from the Playlist Manager toolbar
The importer had exactly two doors, both inside the sidebar's playlist
popup, so the one view whose job is managing playlists could not reach it.

Placed before "New folder": that slot disappears in flat mode and a Row
skips invisible children, so a button after it would slide sideways every
time the mode toggles. No offline gate — the modal recomputes its own and
shows a disabled confirm with the reason, which beats a toolbar button
that vanishes when the network drops.

No new msgids: "Import" is already in all eight catalogs.

cc
2026-08-16 18:53:21 -06:00
vicrodh 16a25bbbe6 fix(qt): pin the Local Library tracks scrollbar to the view edge
The bar sat inside the tab's 32px content inset AND carried its own 4px
margin, leaving it 36px from the window with an empty channel beside it.
It now cancels the inset; the rows keep theirs.

The "By name" arm is untouched: there the alpha strip owns the right edge
and 22px is what clears it. The inset is a named property now because the
scrollbar has to cancel it — written twice, moving one silently misaligns
the other.

cc
2026-08-16 18:53:04 -06:00