Breadway/breadbox
1
0
Fork 0
Code Issues 1 Pull requests 1 Projects Releases Packages Wiki Activity Actions

listen: re-read the shell theme per open, not once per process

Browse source 
`breadbox listen` is the one long-lived breadbox invocation; every other
one is a one-shot window that reads the theme fresh at startup anyway.
`crate::theme::shell_theme()` caches `shell::load()` for the process
lifetime, so after a shell-theme switch `listen` kept deciding
embedded-vs-spawn against the old theme until restarted. It has no glib
main loop to run `shell::watch()`; re-reading on each `open` (rare,
user-driven) is the simple fix.
This commit is contained in:
Breadway 2026-09-02 12:01:59 +08:00
parent feaa88705a
commit a56110e522
1 changed files with 9 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

10
breadbox/src/listen.rs
View file

@ -72,7 +72,15 @@ fn handle_open() {
// own output) and emit a distinct, explicitly-unconfirmed event so a bus
// observer can tell "redirected, outcome unknown" apart from "breadbox
// spawned" rather than being told a specific untrue thing.
if crate::theme::shell_theme().launcher().mode == bread_theme::shell::LauncherMode::Embedded {
// Read the theme fresh, NOT via `crate::theme::shell_theme()`: that
// accessor caches `shell::load()` for the life of the process, and
// `breadbox listen` is long-lived (unlike every other breadbox
// invocation, which is a one-shot window). If the user switches shell
// themes while `listen` is running, a cached value here would make the
// wrong embedded-vs-spawn decision until the next restart. `listen` has
// no glib main loop, so it can't run `shell::watch()`; re-reading on
// each `open` (a rare, user-driven event) is the simplest correct fix.
if bread_theme::shell::load().launcher().mode == bread_theme::shell::LauncherMode::Embedded {
eprintln!(
"breadbox: bread.command.box.open received under an embedded launcher \
theme; breadbar's capsule is the intended handler and this process \