refactor(ui): take the shared vocabulary and widgets from colony-ui - #67
Closed
MotherSphere wants to merge 5 commits into
Closed
refactor(ui): take the shared vocabulary and widgets from colony-ui#67MotherSphere wants to merge 5 commits into
MotherSphere wants to merge 5 commits into
Conversation
src/ui/theme.rs was 2935 lines, 100 KB of it hand-maintained colour constants. It is now 14 lines that re-export colony-ui, whose palettes are generated from the design tokens in Project-Colony-Resources. That file was the reason the Resources repository exists: SphereCord downloaded it over HTTP and regex-parsed the Rust source to recover the palettes, because there was no other way to reach them. There is now. Every call site keeps working — the module re-exports the same ThemePalette, Palette façade, active_palette, app_tint and contrast_on that were defined here, so this is an import-level change rather than a rewrite. 119 tests still pass. Adding a theme family no longer touches this repository at all: add the TOML upstream, regenerate, bump the tag. colony-ui is pinned to v0.1.0 rather than tracking main, so an upstream change cannot break this build without a deliberate bump.
The picker held a 367-line vec listing every family, its Nerd Font glyph, its i18n key, and every variant's swatch colours — the same facts colony-ui already generates from the design tokens, written out a second time by hand. It now iterates colony_ui::THEME_FAMILIES. The card-drawing code below is untouched: the loop binds the same names it did before, so the diff is the catalog disappearing rather than the rendering changing. Swatch colours come typed from the crate now too, which removes two hand-rolled hex-to-Color conversions that did what colony-ui's swatch_bg_color() does. Together with the previous commit this is what the migration was for: adding a theme family used to mean four edits in this repository — a palette const, a resolver arm, an entry in this vec, and both locale files. It now means none. 119 tests still pass.
…yout
Colony resolved its own directories, and got Windows wrong: dirs::config_dir()
is Roaming there, while Digger and Grape both used Local. On Linux the two are
the same function, so nobody could see the disagreement. The layout is defined
once in colony-ui now — see design/filesystem.md upstream — and Local is what it
picks.
Two things move, both handled by migrate_legacy_paths() at startup:
- the config directory, on Windows only (Roaming -> Local); a no-op on Linux
and macOS, where the old and new resolvers return the same path
- the caches, on every platform: repos_cache.json and scan_cache.json lived
inside the config directory and belong in the cache root
The migration never deletes the source. It renames when it can, falls back to a
recursive copy across filesystems (~/.config and ~/.cache are not guaranteed to
share one), and on failure removes the half-written destination so the next
start retries instead of finding an empty directory and skipping. A user who
ends up with a copy in both places has lost nothing; a user whose preferences
were deleted by a half-finished migration has.
Also fixes real test pollution this exposed: with_temp_dirs isolated
XDG_CONFIG_HOME and XDG_DATA_HOME but not XDG_CACHE_HOME, so once the caches
moved, the update tests read and wrote the developer's actual ~/.cache — and
github_error_only_toasts_when_the_catalog_is_empty started failing depending on
what an earlier run had left there. That was a latent hole in the isolation, not
a consequence of the move.
125 tests pass, up from 119.
…cache root repo-docs, repo-icons and update-staging were still under the config directory. All three are re-fetched or recreated when missing — cached documentation, downloaded icons, and a download staging area — so they belong in the cache root with repos_cache and scan_cache. Leaving them behind would have meant a program that half-follows its own documented layout. This surfaced a bug that compiled cleanly: both orphan-pruning functions walked `<config>/repo-docs` and `<config>/repo-icons` to delete caches for repos that no longer exist. Once those directories moved, the pruners would have found nothing and silently stopped reclaiming anything, growing the cache forever. Colony's own test caught the second one after the first was fixed. Also corrects the documentation, which was already wrong before this change and which the move would have made worse. docs/faq.md and docs/architecture.md claimed preferences lived at ~/.config/colony/preferences.json; the code has written ~/.config/Colony/Colony/preferences/preferences.json for some time. Both tables now match the code, and say what the Windows and macOS roots are instead of implying Linux is the only platform. docs/release-signing.md keeps ~/.config/colony/release-signing/ deliberately: that is where a maintainer keeps their own signing key, not state the program owns, and it is the default sign-release.sh already looks for.
Colony already gets its palettes, its resolver, its accents and its filesystem
layout from colony-ui. Two things it kept its own copy of, and both were quietly
broken.
## The theme picker promised something it could not deliver
`view_theme_section` renders from `THEME_FAMILIES`, so a theme family added
upstream reaches the screen with no code change here - that is the whole point of
the generated catalog. But NAMING it still took a hand-written line in
`src/i18n/{fr,en}.rs`, and an upstream change never touches this repository. A
new family would therefore have appeared in the picker labelled
`settings_theme_whatever`.
All 62 shared strings were duplicated in both locale files. They had not drifted
yet, which is the only reason deleting them is safe rather than a merge. The
shared table is now seeded first in `Locale::new`, and a test fails if either
locale file ever redefines one of those keys again - an override is precisely how
this comes back.
`set_language` also moves colony-ui's own active locale now. The shared widgets
call `colony_ui::i18n::t` directly and cannot reach Colony's table, so without
that the theme picker would have stayed English while the rest of the page turned
French.
## The accent list was a local copy of an order that must not move
`view_colors_section` held the eight accents as a `vec![]` of hex literals. They
now come from `ACCENT_OVERRIDES`, generated from `tokens/accents.toml`. The line
count is the least of it: Colony buckets a hash of each installed app's NAME into
that list to pick its identity tint, so an edit here that reordered or inserted an
entry would have silently re-coloured every icon on every user's machine. The
token file says so in a comment; this file said nothing.
## What the widgets do now
`theme_picker`, `accent_picker`, `collapsible_section` and `functional_toggle`
were ported INTO colony-ui from this file, so the two copies were identical
character for character. The four `App` methods stay as one-line facades over the
crate: the expanded set, the messages and the fonts are the host's, the drawing is
the crate's. That split is why none of the twenty-seven call sites changed.
`App::typo()` is the bridge - a widget in the crate cannot reach `App`, so the
three fonts and the combined font scale are handed over explicitly.
481 lines deleted, 202 added, 130 tests green.
One of them had to be serialised: the active locale is process-wide, so a test
that sets it and reads it back cannot run beside another that sets it too.
Member
Author
|
Annulé : hors périmètre. |
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.
Colony already gets its palettes, its resolver, its accents and its filesystem layout from
colony-ui. Two things it kept its own copy of, and both were quietly broken.The theme picker promised something it could not deliver
view_theme_sectionrenders fromTHEME_FAMILIES, so a theme family added upstream reaches the screen with no code change here - that is the whole point of the generated catalog.But naming it still took a hand-written line in
src/i18n/{fr,en}.rs, and an upstream change never touches this repository. A new family would therefore have appeared in the picker labelledsettings_theme_whatever.All 62 shared strings were duplicated in both locale files. They had not drifted yet, which is the only reason deleting them is safe rather than a merge. The shared table is now seeded first in
Locale::new, andno_shared_key_is_redefined_locallyfails if either locale file ever redefines one of those keys again - an override is precisely how this comes back.set_languagealso moves colony-ui's own active locale now. The shared widgets callcolony_ui::i18n::tdirectly and cannot reach Colony's table, so without that the theme picker would have stayed English while the rest of the page turned French.The accent list was a local copy of an order that must not move
view_colors_sectionheld the eight accents as avec![]of hex literals. They now come fromACCENT_OVERRIDES, generated fromtokens/accents.toml.The line count is the least of it. Colony buckets a hash of each installed app's name into that list to pick its identity tint, so an edit here that reordered or inserted an entry would have silently re-coloured every icon on every user's machine. The token file says so in a comment; this file said nothing. Values and order verified identical before the swap.
The widgets
theme_picker,accent_picker,collapsible_sectionandfunctional_togglewere ported into colony-ui from this file, so the two copies were identical character for character.The four
Appmethods stay as one-line facades over the crate: the expanded set, the messages and the fonts are the host's, the drawing is the crate's. That split is why none of the twenty-seven call sites changed.App::typo()is the bridge - a widget in the crate cannot reachApp, so the three fonts and the combined font scale are handed over explicitly.Result
--all-targets -D warningsOne test had to be serialised: the active locale is process-wide, so a test that sets it and reads it back cannot run beside another that sets it too. Hammered 40 consecutive runs to confirm.