fix(theme): scope the remembered theme choice per profile - #336
Merged
Merged
Conversation
Running two OpenVTC instances under different local profiles and changing the
theme in one changed it in all of them. The theme choice was kept in a single
`<config>/tui.toml` shared by every profile, and a live file-watcher even
repainted the other running instances immediately. Everything that matters was
already isolated per profile (secrets/keyring, the whole config + account data,
log settings, the process lock — all carry the profile in their filename); only
the cosmetic theme choice, and a transient crash-report file, crossed over.
Make the theme choice per-profile, matching the `config-{profile}.json`
convention the main config already uses:
- `Roots` gains a `profile`; the choice file is `tui.toml` for the `default`
profile and `tui-{profile}.toml` for any other. The theme *library*
(`themes/`) stays shared — it is authored content, not a per-profile setting.
- `main.rs` resolves the profile *before* choosing the theme (profile resolution
factored into `resolve_profile`), so the theme is scoped to it. The
informational profile messages now print with the default palette, since the
theme is not chosen yet — a rare, acceptable trade.
- The TUI settings theme actions and the `openvtc theme` CLI both read/write the
running profile's file. The live watcher watches that file, so two instances
of the *same* profile still stay in sync while different profiles do not.
- Also fix the one other cross-profile collision the investigation found: the
startup crash report is now `last-startup-failure-{profile}.txt`
(unsuffixed for `default`), so one profile's report no longer overwrites
another's.
Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
Running two OpenVTC instances under different local profiles and changing the theme in one changed it in all of them — and, via a live file-watcher, repainted the other running instances immediately.
Root cause
The theme choice was kept in a single
<config>/tui.tomlshared by every profile (this was intentional — "how the TUI looks is the person's, not the account's"), while every other profile-scoped surface encodes the profile into its filename. So two instances differing only by--profileread and wrote the same file.Blast radius (what else crossed profiles): only the cosmetic theme keys (
theme,auto_dark,auto_light) and a transientlast-startup-failure.txtcrash report. Everything that matters — secrets/keyring, the whole config + account/community data, log settings, the process lock — is already correctly isolated per profile.The fix (theme now fully per-profile)
Rootsgains aprofile; the choice file istui.tomlfor thedefaultprofile andtui-{profile}.tomlotherwise, mirroring theconfig-{profile}.jsonconvention. The theme library (themes/) stays shared — it's authored content, not a per-profile setting.main.rsresolves the profile before choosing the theme (profile resolution factored into aresolve_profilehelper). Its informational messages now print with the default palette since the theme isn't chosen yet — a rare, acceptable trade.openvtc themeCLI both read/write the running profile's file. The live watcher watches that file, so two instances of the same profile still stay in sync while different profiles no longer cross.last-startup-failure-{profile}.txt(unsuffixed fordefault).Tests / gates
settings_file_is_scoped_per_profileunit test (default →tui.toml, named →tui-{profile}.toml, two profiles differ).cargo fmt,clippy --all-targets --all-features,RUSTDOCFLAGS="-D warnings" cargo doc, and fullcargo test(694 core + 611 openvtc + census) all pass.Note
This reverses a previously-intentional design (theme as a person-level, cross-profile preference) in favour of strict per-profile isolation, per the reporter's requirement that instances be fully isolated.