breadman: watch bread-theme's palette cache instead of ~/.cache/wal #9
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feature/drop-pywal"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
breadman's theme watcher (
breadman/src/theme.rs) watched~/.cache/walfor palette changes. Once bread-theme moves the global palette to its own bread-owned cache path, that watch goes stale and breadman stops recolouring on wallpaper change.watched_dirs()now watchesbread_theme::palette_cache_dir()(a path helper) instead of a hardcodeddirs::cache_dir().join("wal").stylesheet()'s signature to take a leading&Typographyargument; updatedbreadpad-shared::theme::build_css()to passTypography::default().README.md,breadman/ui/src/app.css,breadpad-shared/src/theme.rs, andbreadpad/src/main.rs.Dependency note:
bread-themeis pointed at thefeature/native-palettebranch of bread-ecosystem (which carries thepalette_cache_dirhelper) instead of a tag. This must be switched to the real release tag before merge, andCargo.lockneeds a refresh once that branch is pushed/released; it's left at the prior lock entry for now since the branch isn't fetchable from a clean clone yet.Verified:
cargo check --workspace,cargo clippy --workspace --all-targets -- -D warnings,cargo test --workspace, all clean (this repo'scheck.ymlruns clippy + test, no fmt gate; pre-existing unrelatedcargo fmtdrift in breadman/src/main.rs and breadpad/src/main.rs was left untouched). Sincefeature/native-paletteisn't pushed yet, these were run with a temporary, uncommitted local path override to the in-progress bread-theme worktree, then reverted; the committedCargo.toml/Cargo.lockstate was not built against that override.Closes #8
Review: approve pending bread-theme release (not merging now)
The code change is correct:
bread_theme::palette_cache_dir()(breadman/src/theme.rs:33) instead of~/.cache/wal. That is the directorywrite_global_palettewritespalette.jsoninto.stylesheet()call site was updated for the new&Typographyparameter (breadpad-shared/src/theme.rs:41).In a clean clone the branch builds without
--locked.Blocking before merge:
check / check (push). The committed Cargo.lock does not matchbranch = "feature/native-palette". I reproduced this in a clean clone:cargo metadata --lockedreports "cannot update the lock file". Once bread-ecosystem#36 is reworked and released, re-point bothbreadman/Cargo.toml:33andbreadpad-shared/Cargo.toml:10to the release tag, commit the regenerated Cargo.lock, and get CI green.Nits (non-blocking):
breadpad-shared/src/theme.rs:41passesTypography::default(). bread-theme's ownwrite_shared_css_fromusesTypography::active(), which follows the shell theme's tokens. With default, breadpad's app rules can disagree on font and size with the shared sheet under a custom shell theme. Default preserves the pre-bump behaviour, so it is fine if that is deliberate. If not, useactive().watched_dirs()drops directories that do not exist yet (retain(|d| d.exists())). On a fresh install where~/.cache/breadhas not been created, the palette dir is never watched. The runtimetheme.csswatch still catches reloads, so this is low impact. Watching the parent, or creating the dir first, would make it robust.The acceptance criteria for PAD-8 (watch bread-theme's cache instead of
~/.cache/wal, reword pywal mentions, bump bread-theme) are met, apart from the tag. PAD-8 stays in review until the relock lands.Pushed a follow-up commit addressing both nits:
watched_dirs()now createsbread_theme::palette_cache_dir()(best-effort, logs a warning on failure) before theretain(exists)filter, so a fresh install where breadpaper hasn't written a palette yet still gets that dir watched, and the very first write is seen.breadpad-shared'sbuild_css()now passesTypography::active()instead ofTypography::default()tostylesheet(), so breadpad/breadman follow the active shell theme's font tokens like the rest of the ecosystem.Also refreshed Cargo.lock against feature/native-palette's latest commit (3758f0c), verified
cargo build --workspace --lockedin a fresh clone. Still points at the branch; will need the lock refreshed once more when bread-theme cuts its release tag.Verified: cargo check --workspace, cargo clippy --workspace --all-targets -- -D warnings, cargo test --workspace, all clean.
Second-round review: one doc line, plus the relock (not merging)
CI is green on
c485999(run 135, fresh clone building bread-theme at 3758f0c), and the PR is mergeable.The round-1 nits are resolved:
breadman/src/theme.rs:33-45createsbread_theme::palette_cache_dir()before theretain(exists)filter, so the first palette write on a fresh install is seen. A failed create is logged, not fatal.breadpad-shared/src/theme.rs:41now usesTypography::active(). That matches bread-theme's ownwrite_shared_css_from(Typography::from_tokens(shell::load().tokens()), infallible becauseshell::loadfalls back to the builtin).Change requests
README.md:82"Falls back to Catppuccin Mocha" is wrong. It is the same stale claim fixed in breadbar#25.load_palette()falls back to~/.cache/wal/colors.jsonand then bread-theme'sPalette::default()(fixed BOS dark base, bread-toned accents). breadpad has no Catppuccin fallback of its own. Reword lines 81-82 to match, for example: "bread-theme's palette cache, then a legacy pywal colors.json, then bread-theme's built-in default".breadman/Cargo.toml:33andbreadpad-shared/Cargo.toml:10frombranch = "feature/native-palette"to the release tag, and commit the regenerated Cargo.lock.Acceptance criteria (PAD-8), as I read them
~/.cache/wal. Met.Rework happens on the existing branch
feature/drop-pywal, and PR #9 stays open. Do not open a second PR for this key.Round-3 update, addressing the second-round review:
colors.jsoncache if present, then bread-theme's own built-in bread-toned default palette.Cargo.lockagainst bread-theme's latestfeature/native-palettecommit (the licensing split that moved image extraction into a separate optionalbread-palette-extractdependency). Confirmed neitherbreadmannorbreadpad-sharedenables bread-theme's newextractfeature, and nothing here callspalette_from_image/pywal_colors/generate_output, so this crate stays extraction-free as intended.Verified:
cargo build --workspace --locked,cargo test --workspace --locked(all passed),cargo clippy --workspace --all-targets --locked -- -D warnings, matching this repo's actual CI gate.Still needed before merge: repin both
Cargo.tomlfiles from thefeature/native-palettebranch to the release tag once bread-ecosystem's release goes out, and relock again.Third-round review (round-3 commit
8b7b213): approved, pending the bread-theme tag, a repin and a rebase (not merging)CI is green on
8b7b213. The PR is not mergeable: main gained #10 (dev-deps CI plus the sameTypography::active()fix), #11 and #12.Round-3 change
README.md:82now describes the real fallback chain: bread-theme cache, then legacy wal colors.json, then bread-theme's default. It is accurate. This PR does not enableextract, which is correct: breadpad never extracts from an image.Overlap with main (#10): trivial
I test-rebased in a throwaway clone (not pushed, since deleted).
breadpad-shared/src/theme.rsconflicts twice. In030edb5the PR hasTypography::default()where main hasTypography::active(). Inc485999the PR changes it toactive()while main added a comment. Take main's side both times. After the rebase the PR'stheme.rsdiff is only the pywal comment rewording, and the Typography change disappears as already landed. Nothing else conflicts.With the pins swapped to a tag and bread-theme patched to a rebased bread-ecosystem#36 (what dev-deps.sh does in CI),
cargo clippy --workspace --all-targets -D warningsis clean,cargo test --workspacepasses, andcargo treeshows no bread-palette-extract, so no licence leak.Required before merge (sequencing, not rework)
breadpad-shared/Cargo.tomlandbreadman/Cargo.tomlfrombranch = "feature/native-palette"to the bread-ecosystem tag that ships #36, thencargo update -p bread-themeand commit the lockfile. Main's check.yml now runslint-pins.sh, which fails on a branch pin. Note that breadpad main itself is unreleasable on its currentv0.7.4pin: v0.7.4'sstylesheettakes one argument, and main's #10 already calls the two-argument form, so rc/release--lockedbuilds fail until this repin lands anyway.Everything else is approved. The issue stays in review.
8b7b21398461befb76d1