29 lines
5.0 KiB
Markdown
29 lines
5.0 KiB
Markdown
FAIL
|
|
|
|
Checked: `cargo test -p ely-ui -p ely-platform` passes (ely-ui 6 unit tests, ely-platform 10 + 12 + startup_panic). `tests/scripts/theme.sh` passes on macOS. `cargo clippy --all-targets` on both crates is clean. The three fixtures match `themes/{tokyo-night,catppuccin-latte,white}/colors.toml` in basecamp/omarchy at f45461a, so the "real palettes" claim holds. Contrast numbers below come from a probe crate outside the repo that `#[path]`-includes `omarchy.rs` and calls `parse` on the fixtures.
|
|
|
|
1. crates/ely-ui/src/theme/omarchy.rs:73 (and the test at :244)
|
|
What is wrong: `readable` and `toward_bg` lift text only against `bg`. The test also checks only against `p.bg`. The components put this text on `surface`, `sunken`, `hover`, `active` and `selection`, which are mixed toward `fg`, so the lifted colors drop below 4.5 there. Ely's own palettes stay at or above 4.5 on every one of those surfaces except `selection`. The TASKS line ("全部正文色达 4.5:1") and agents.md ("每个正文色拉到 4.5:1") claim more than the code does.
|
|
Failing scenario: catppuccin-latte gives `fg_muted` on `surface` 4.35, `fg_subtle` on `surface` 4.30 and on `active` 3.70. tokyo-night gives `fg_subtle` on `surface` 4.20 and on `active` 3.44. white gives `fg_subtle` on `sunken` 3.98. `shell::OfflineIndicator` (status.rs:128,133) draws `fg_muted` on `surface`, so under catppuccin-latte its label reads 4.35:1.
|
|
Fix direction: lift each text token against the darkest or lightest surface it is drawn on (bg, surface, sunken, hover, active), not just bg. Extend the test to assert every text token against each of those surfaces.
|
|
|
|
2. crates/ely-ui/src/theme/omarchy.rs:75-84
|
|
What is wrong: only the named keys (`red`, `green`, `blue`, …, `selection`) are read. Omarchy v4's own `colors.toml` format also carries `color0`..`color15`, `purple`/`bright_purple` and `selection_background`. Omarchy's resolver (`bin/omarchy-theme-color`) aliases red→color1, green→color2, yellow→color3, blue→color4, magenta→color5/purple, cyan→color6, and selection→selection_background. `omarchy-theme-colors-from-alacritty` writes only `accent`, `selection`, `background`, `foreground` and `color0`..`color15`. Every theme without its own `colors.toml` (for example a user or git-installed theme that ships `alacritty.toml`) therefore reaches Ely in that form. Each missing hue then silently becomes Ely's default through `unwrap_or(p.danger)` and the like, with no log line. That is a default value hiding missing data (rule 2), and the theme is not synced.
|
|
Failing scenario: parse a generated file (`accent`, `selection`, `background`, `foreground`, `color0`..`color7` from Tokyo Night). The probe shows `palette.danger == Palette::dark(false).danger` and `success` equal to Ely's default. Syntax `keyword` comes from Ely's chart, not the theme's `color5`. Danger, success, warning, info, chart, ANSI and syntax colors all show Ely's palette under an Omarchy theme.
|
|
Fix direction: resolve keys with Omarchy's alias cascade (named key, then `colorN`, then `purple`/`selection_background`). Where a key is still missing, log it rather than substituting silently, and add a fixture in the generated `colorN` form.
|
|
|
|
3. crates/ely-ui/src/theme/mod.rs:37
|
|
What is wrong: `ELY_OMARCHY_SYNC` treats every value except `"0"` as on, without a warning. `ELY_APPEARANCE` (:32) and `ELY_REDUCE_MOTION` (accessibility.rs:20) both warn on an invalid value. This is a silent fallback on a documented 0/1 switch.
|
|
Failing scenario: `ELY_OMARCHY_SYNC=false` or `off` leaves Omarchy sync on, and the log does not say the value was ignored.
|
|
Fix direction: match `"0"`, `"1"` and unset explicitly, and warn on anything else, as the other two switches do.
|
|
|
|
4. crates/ely-ui/src/theme/watch.rs:40
|
|
What is wrong: when the live theme directory has no `colors.toml`, `reload` logs at debug and keeps the previous `OmarchyState`. The app keeps showing the theme the user just left.
|
|
Failing scenario: the app runs under tokyo-night, and the user runs `omarchy-theme-set` with a user theme that has no `colors.toml` and no `alacritty.toml`, so Omarchy writes none. `theme/` is swapped and `theme.name` changes, but Ely stays on the tokyo-night palette. Nothing above debug level records this.
|
|
Fix direction: on `Ok(None)` after a change, clear `OmarchyState`, re-apply (Ely's palette or the chosen appearance), and log at info.
|
|
|
|
5. crates/ely-platform/src/dirs.rs:19-21
|
|
What is wrong: the default Omarchy directory comes from `BaseDirs::state_dir()`, which honours `$XDG_STATE_HOME`. Omarchy hardcodes `$HOME/.local/state/omarchy/current` (`bin/omarchy-theme-set`: `CURRENT_THEME_PATH="$HOME/.local/state/omarchy/current/theme"`).
|
|
Failing scenario: on an Omarchy machine with `XDG_STATE_HOME=$HOME/.state`, Ely looks in `~/.state/omarchy/current`, logs "no Omarchy on this machine", and never syncs.
|
|
Fix direction: build the path from the home directory as `.local/state/omarchy/current` to match Omarchy, with `ELY_OMARCHY_DIR` still taking precedence.
|