User feedback after delivery 26: "wheres white and black themes?" -
the previous "Light" theme (white bg, black text) was a reasonable
literal reading of "have white/black" as one combined theme, but the
user meant two distinct named themes.
Renamed that theme's id/label from "light" to "White" and added a
genuinely new "Black" theme: a true near-black background with a
deliberately grayscale accent (light neutral grays instead of any
hue), so it reads as an actual black-and-white theme rather than
"Aurora but darker" - Aurora already covers the teal/green-accented
dark look. White keeps its colorful green/cyan/lilac accents, which
is now the visual difference between the two beyond just background
color. Settings now lists 5 themes total (Aurora/White/Black/Ocean/
Sunset); the picker grid moved from 2 to 3 columns to fit them
better.
Verified with an expanded Playwright script (12 checks, up from 10):
confirms all 5 themes list correctly, White and Black each apply
their real computed background color (not just the data-theme
attribute) and persist via save_theme, and the rest of the boot-time/
persistence behavior from delivery 26 still holds. All prior
verification suites (47 checks), `cargo test --workspace` (162
tests), and `npm run build` still pass clean.
Requested directly: "lets add some themeing into it now, perhaps
under the configuration, have white/black, and some more colors."
There was no existing app-wide Settings/Configuration surface -
every prior setting lived in its own panel-specific modal (Fetch
Data Settings, subtitle provider settings) - so this adds the
app's first one: a palette-icon button in the sidebar footer opens
a new Settings modal with a 2x2 grid of theme swatches.
Four themes: Aurora (the existing dark teal/green look, unchanged,
stays the default), Light (a clean white/black theme - the literal
"white/black" ask), Ocean (a cool blue-toned dark variant), and
Sunset (a warm amber-toned dark variant) - the "some more colors"
part. Picking one applies instantly via a `data-theme` attribute on
<html> and persists through new get_theme/save_theme commands
(added to settings.rs/lib.rs alongside delivery 25's movie-naming-
scheme fix), applied on every future launch by a boot-time effect
in App.tsx so it takes effect even if Settings is never reopened.
theme.css's variable set was expanded to cover every place a color
was previously hardcoded outside the existing --dock/--surface/etc.
variables, so the whole app actually re-themes instead of leaving
dark boxes behind on the Light theme: button resting/hover/active
shades, the Load-files popup background, the primary button's hover
tint, the header's gradient stops, and five levels of white-tint
row/button hover highlights (RenamePanel.css/Header.css) all moved
to new variables (--btn-bg*, --popup-bg, --accent-hover, --header-
grad-a/b, --tint-02/03/05/06/16) with theme-specific values - the
light theme in particular needed dark tints instead of white ones
for hover states to stay visible on a white background.
Verified with a new Playwright script covering: default theme on a
fresh install, the Settings modal listing all 4 themes with the
right one marked selected, clicking a theme applying it immediately
(actual computed background color and CSS variable checked, not
just the data-theme attribute) and saving it, and a previously-saved
theme applying on boot before Settings is ever opened. Screenshots
taken of all 4 themes across the main view and the Naming Scheme
editor (whose buttons/popups were part of the hardcoded-color
cleanup) to confirm visually. All prior verification suites (47
checks across naming-scheme/match-fetch/hash-files/movie-scheme),
`cargo test --workspace` (162 tests), and `npm run build` still
pass clean.
Renamr Scaffold