breadman: watch bread-theme's palette cache instead of ~/.cache/wal #9

Merged
Breadway merged 4 commits from feature/drop-pywal into main 2026-09-29 13:12:52 +08:00
Owner

breadman's theme watcher (breadman/src/theme.rs) watched ~/.cache/wal for 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 watches bread_theme::palette_cache_dir() (a path helper) instead of a hardcoded dirs::cache_dir().join("wal").
  • Bumps the bread-theme dependency, which also changed stylesheet()'s signature to take a leading &Typography argument; updated breadpad-shared::theme::build_css() to pass Typography::default().
  • Rewords remaining pywal mentions in README.md, breadman/ui/src/app.css, breadpad-shared/src/theme.rs, and breadpad/src/main.rs.

Dependency note: bread-theme is pointed at the feature/native-palette branch of bread-ecosystem (which carries the palette_cache_dir helper) instead of a tag. This must be switched to the real release tag before merge, and Cargo.lock needs 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's check.yml runs clippy + test, no fmt gate; pre-existing unrelated cargo fmt drift in breadman/src/main.rs and breadpad/src/main.rs was left untouched). Since feature/native-palette isn't pushed yet, these were run with a temporary, uncommitted local path override to the in-progress bread-theme worktree, then reverted; the committed Cargo.toml/Cargo.lock state was not built against that override.

Closes #8

breadman's theme watcher (`breadman/src/theme.rs`) watched `~/.cache/wal` for 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 watches `bread_theme::palette_cache_dir()` (a path helper) instead of a hardcoded `dirs::cache_dir().join("wal")`. - Bumps the bread-theme dependency, which also changed `stylesheet()`'s signature to take a leading `&Typography` argument; updated `breadpad-shared::theme::build_css()` to pass `Typography::default()`. - Rewords remaining pywal mentions in `README.md`, `breadman/ui/src/app.css`, `breadpad-shared/src/theme.rs`, and `breadpad/src/main.rs`. Dependency note: `bread-theme` is pointed at the `feature/native-palette` branch of bread-ecosystem (which carries the `palette_cache_dir` helper) instead of a tag. This must be switched to the real release tag before merge, and `Cargo.lock` needs 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's `check.yml` runs clippy + test, no fmt gate; pre-existing unrelated `cargo fmt` drift in breadman/src/main.rs and breadpad/src/main.rs was left untouched). Since `feature/native-palette` isn't pushed yet, these were run with a temporary, uncommitted local path override to the in-progress bread-theme worktree, then reverted; the committed `Cargo.toml`/`Cargo.lock` state was not built against that override. Closes #8
fix: watch bread-theme's palette cache instead of ~/.cache/wal
Some checks failed
check / check (push) Failing after 1m45s
030edb5dec
breadman's theme watcher now watches bread_theme::palette_cache_dir()
instead of a hardcoded ~/.cache/wal, so it keeps recolouring once the
global palette moves to bread's own cache path.

Bumps bread-theme, which also drops a Typography parameter into
stylesheet(); pass Typography::default() from breadpad-shared's
build_css() to keep up.

Rewords remaining pywal mentions in README, breadman/ui/src/app.css,
breadpad-shared/src/theme.rs and breadpad/src/main.rs.

Points bread-theme at the feature/native-palette branch of
bread-ecosystem for its new palette cache path helper; this must move
to the real release tag before merge, and Cargo.lock needs a refresh
once that branch exists.
Author
Owner

Review: approve pending bread-theme release (not merging now)

The code change is correct:

  • breadman's watcher now watches bread_theme::palette_cache_dir() (breadman/src/theme.rs:33) instead of ~/.cache/wal. That is the directory write_global_palette writes palette.json into.
  • The stylesheet() call site was updated for the new &Typography parameter (breadpad-shared/src/theme.rs:41).
  • The wording changes are accurate.

In a clean clone the branch builds without --locked.

Blocking before merge:

  • CI is red: check / check (push). The committed Cargo.lock does not match branch = "feature/native-palette". I reproduced this in a clean clone: cargo metadata --locked reports "cannot update the lock file". Once bread-ecosystem#36 is reworked and released, re-point both breadman/Cargo.toml:33 and breadpad-shared/Cargo.toml:10 to the release tag, commit the regenerated Cargo.lock, and get CI green.

Nits (non-blocking):

  • breadpad-shared/src/theme.rs:41 passes Typography::default(). bread-theme's own write_shared_css_from uses Typography::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, use active().
  • watched_dirs() drops directories that do not exist yet (retain(|d| d.exists())). On a fresh install where ~/.cache/bread has not been created, the palette dir is never watched. The runtime theme.css watch 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.

## Review: approve pending bread-theme release (not merging now) The code change is correct: - breadman's watcher now watches `bread_theme::palette_cache_dir()` (`breadman/src/theme.rs:33`) instead of `~/.cache/wal`. That is the directory `write_global_palette` writes `palette.json` into. - The `stylesheet()` call site was updated for the new `&Typography` parameter (`breadpad-shared/src/theme.rs:41`). - The wording changes are accurate. In a clean clone the branch builds without `--locked`. **Blocking before merge:** - CI is red: `check / check (push)`. The committed Cargo.lock does not match `branch = "feature/native-palette"`. I reproduced this in a clean clone: `cargo metadata --locked` reports "cannot update the lock file". Once bread-ecosystem#36 is reworked and released, re-point both `breadman/Cargo.toml:33` and `breadpad-shared/Cargo.toml:10` to the release tag, commit the regenerated Cargo.lock, and get CI green. **Nits (non-blocking):** - `breadpad-shared/src/theme.rs:41` passes `Typography::default()`. bread-theme's own `write_shared_css_from` uses `Typography::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, use `active()`. - `watched_dirs()` drops directories that do not exist yet (`retain(|d| d.exists())`). On a fresh install where `~/.cache/bread` has not been created, the palette dir is never watched. The runtime `theme.css` watch 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.
fix: address review nits on breadman theme watcher
All checks were successful
check / check (push) Successful in 2m57s
c485999111
Create bread-theme's palette cache dir before filtering watched_dirs():
retain(exists) previously dropped it on a fresh install (before
breadpaper has ever written a palette), so notify never picked up the
very first write once the directory did appear.

Use Typography::active() instead of Typography::default() in
breadpad-shared's stylesheet() call, so breadpad/breadman follow the
active shell theme's font tokens like the rest of the ecosystem
instead of always using bread-theme's static built-in defaults.

Refreshes Cargo.lock against feature/native-palette's latest commit.
Author
Owner

Pushed a follow-up commit addressing both nits:

  1. watched_dirs() now creates bread_theme::palette_cache_dir() (best-effort, logs a warning on failure) before the retain(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.
  2. breadpad-shared's build_css() now passes Typography::active() instead of Typography::default() to stylesheet(), 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 --locked in 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.

Pushed a follow-up commit addressing both nits: 1. `watched_dirs()` now creates `bread_theme::palette_cache_dir()` (best-effort, logs a warning on failure) before the `retain(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. 2. `breadpad-shared`'s `build_css()` now passes `Typography::active()` instead of `Typography::default()` to `stylesheet()`, 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 --locked` in 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.
Author
Owner

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-45 creates bread_theme::palette_cache_dir() before the retain(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:41 now uses Typography::active(). That matches bread-theme's own write_shared_css_from (Typography::from_tokens(shell::load().tokens()), infallible because shell::load falls 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.json and then bread-theme's Palette::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".
  • Relock (blocked until the release): after bread-ecosystem#36 is released, repin breadman/Cargo.toml:33 and breadpad-shared/Cargo.toml:10 from branch = "feature/native-palette" to the release tag, and commit the regenerated Cargo.lock.

Acceptance criteria (PAD-8), as I read them

  1. breadman watches bread-theme's cache instead of ~/.cache/wal. Met.
  2. The pywal wording is reworded. Met, except for the fallback line above.
  3. bread-theme is bumped. Met on the branch, and the tag pin is pending.

Rework happens on the existing branch feature/drop-pywal, and PR #9 stays open. Do not open a second PR for this key.

## 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-45` creates `bread_theme::palette_cache_dir()` before the `retain(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:41` now uses `Typography::active()`. That matches bread-theme's own `write_shared_css_from` (`Typography::from_tokens(shell::load().tokens())`, infallible because `shell::load` falls 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.json` and then bread-theme's `Palette::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". - [ ] **Relock (blocked until the release):** after bread-ecosystem#36 is released, repin `breadman/Cargo.toml:33` and `breadpad-shared/Cargo.toml:10` from `branch = "feature/native-palette"` to the release tag, and commit the regenerated Cargo.lock. ### Acceptance criteria (PAD-8), as I read them 1. breadman watches bread-theme's cache instead of `~/.cache/wal`. Met. 2. The pywal wording is reworded. Met, except for the fallback line above. 3. bread-theme is bumped. Met on the branch, and the tag pin is pending. Rework happens on the existing branch `feature/drop-pywal`, and PR #9 stays open. Do not open a second PR for this key.
docs: fix stale theme fallback claim, relock bread-theme
All checks were successful
check / check (push) Successful in 2m2s
8b7b213984
README.md:82 said breadpad falls back to Catppuccin Mocha; it actually
falls back to a legacy wal colors.json cache if present, then bread-theme's
own built-in bread-toned default palette. Same fix breadbar#25 needed.

Relocked Cargo.lock against bread-theme's latest feature/native-palette
commit (its licensing split moved image extraction into a separate
optional bread-palette-extract dependency). Confirmed neither breadman nor
breadpad-shared enables bread-theme's extract feature and nothing here
calls palette_from_image/pywal_colors/generate_output, so this stays
extraction-free as intended; the image/gif/webp decode dependencies drop
out of the lockfile entirely as a result.

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 (clippy + test; this repo
does not run cargo fmt --check).
Author
Owner

Round-3 update, addressing the second-round review:

  • README.md:82: fixed the stale "Falls back to Catppuccin Mocha" claim; it actually falls back to a legacy wal colors.json cache if present, then bread-theme's own built-in bread-toned default palette.
  • Relocked Cargo.lock against bread-theme's latest feature/native-palette commit (the licensing split that moved image extraction into a separate optional bread-palette-extract dependency). Confirmed neither breadman nor breadpad-shared enables bread-theme's new extract feature, and nothing here calls palette_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.toml files from the feature/native-palette branch to the release tag once bread-ecosystem's release goes out, and relock again.

Round-3 update, addressing the second-round review: - README.md:82: fixed the stale "Falls back to Catppuccin Mocha" claim; it actually falls back to a legacy wal `colors.json` cache if present, then bread-theme's own built-in bread-toned default palette. - Relocked `Cargo.lock` against bread-theme's latest `feature/native-palette` commit (the licensing split that moved image extraction into a separate optional `bread-palette-extract` dependency). Confirmed neither `breadman` nor `breadpad-shared` enables bread-theme's new `extract` feature, and nothing here calls `palette_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.toml` files from the `feature/native-palette` branch to the release tag once bread-ecosystem's release goes out, and relock again.
Author
Owner

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 same Typography::active() fix), #11 and #12.

Round-3 change

README.md:82 now 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 enable extract, 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.rs conflicts twice. In 030edb5 the PR has Typography::default() where main has Typography::active(). In c485999 the PR changes it to active() while main added a comment. Take main's side both times. After the rebase the PR's theme.rs diff 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 warnings is clean, cargo test --workspace passes, and cargo tree shows no bread-palette-extract, so no licence leak.

Required before merge (sequencing, not rework)

  • Rebase onto main as above.
  • Repin both breadpad-shared/Cargo.toml and breadman/Cargo.toml from branch = "feature/native-palette" to the bread-ecosystem tag that ships #36, then cargo update -p bread-theme and commit the lockfile. Main's check.yml now runs lint-pins.sh, which fails on a branch pin. Note that breadpad main itself is unreleasable on its current v0.7.4 pin: v0.7.4's stylesheet takes one argument, and main's #10 already calls the two-argument form, so rc/release --locked builds fail until this repin lands anyway.

Everything else is approved. The issue stays in review.

## 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 same `Typography::active()` fix), #11 and #12. ### Round-3 change `README.md:82` now 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 enable `extract`, 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.rs` conflicts twice. In 030edb5 the PR has `Typography::default()` where main has `Typography::active()`. In c485999 the PR changes it to `active()` while main added a comment. Take main's side both times. After the rebase the PR's `theme.rs` diff 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 warnings` is clean, `cargo test --workspace` passes, and `cargo tree` shows no bread-palette-extract, so no licence leak. ### Required before merge (sequencing, not rework) - [ ] Rebase onto main as above. - [ ] Repin both `breadpad-shared/Cargo.toml` and `breadman/Cargo.toml` from `branch = "feature/native-palette"` to the bread-ecosystem tag that ships #36, then `cargo update -p bread-theme` and commit the lockfile. Main's check.yml now runs `lint-pins.sh`, which fails on a branch pin. Note that breadpad main itself is unreleasable on its current `v0.7.4` pin: v0.7.4's `stylesheet` takes one argument, and main's #10 already calls the two-argument form, so rc/release `--locked` builds fail until this repin lands anyway. Everything else is approved. The issue stays in review.
Breadway force-pushed feature/drop-pywal from 8b7b213984
All checks were successful
check / check (push) Successful in 2m2s
to 61befb76d1
All checks were successful
check / check (push) Successful in 8m31s
2026-09-29 13:03:44 +08:00
Compare
Breadway deleted branch feature/drop-pywal 2026-09-29 13:12:52 +08:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Breadway/breadpad!9
No description provided.