refactor(client): put the modal dialog buttons on tokens, readably (UI/UX v3 G11 follow-up) - #71
Merged
Conversation
…I/UX v3 G11 follow-up) Third and last code half of the #62 follow-up: the close-window dialog's Kill/Cancel buttons, and the consent dialog's selected-button fill. The literals were `[0.75, 0.25, 0.25]` / `[0.95, 0.40, 0.40]` for Kill at rest and selected, `[0.95, 0.85, 0.40]` for a selected Cancel, and `[0.10, 0.10, 0.10]` for the label on any selected button (in two dialogs). All now derive from `semantic_error` / `semantic_warning` via two new helpers, `util::danger_fill` and `util::caution_fill`. Kill deliberately does *not* reuse #70's `danger_button_colors`. That helper answers "is this button focused", stepping from a barely-tinted rest state to a mid blend. Kill has to read as the destructive choice *before* it is selected — it sits next to Cancel — so it steps from the mid blend to a strong one instead. Sharing the blend and not the focused/unfocused rule is what keeps both readings intact. The labels are the substance of this change. Selected-button labels were a fixed near-black, which is wrong on any dark fill; they now come from `on_surface_text`, chosen against the fill. Measuring that across the nine built-in schemes turned up something a fixed blend strength cannot fix: at 0.85 the error hue lands at a middling luminance on Nord (4.42:1) and the warning hue does the same on Solarized (4.37:1) — luminances where *neither* extreme has anything to contrast with. Used raw, `semantic_warning` fails the same way, which is why `caution_fill` blends rather than passing the token through. `semantic_fill` therefore walks the blend back toward `surface_1` until the label clears `MIN_TEXT_CONTRAST`, the same shape as `row::ensure_readable`. It terminates because `surface_1` derives from the scheme background — the end of the range a label can always be read against. Some schemes get a slightly quieter fill than asked for; an unreadable label on a destructive button is the worse trade. The consent dialog's 3 px top stripe and its title keep the raw warning hue: a line and text, not a fill. Two new tests. One pins every fill/label pair the dialogs paint across all nine schemes at 4.5:1 — it is the test that forced `caution_fill` to exist, and it fails on `Nord` if the adaptive step is removed. The other pins that a stronger blend always reads as redder, since that ordering is what carries "dangerous" and "selected". On-device verification: not run. Joins the accepted-unverified backlog. Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering>
Coverage reportGenerated by |
3 tasks
mizu-jun
added a commit
that referenced
this pull request
Aug 21, 2026
) The follow-up entry has been an open checkbox holding a list of sites since #62. It now records what was actually done in #69 / #70 / #71, split by surface, plus the two sites that stay out and why they are decisions rather than leftovers: `picker.rs`'s per-feature brand hues need a product call, and `resolve_color`'s no-palette fallbacks sit on a branch `render_frame` cannot reach outside tests. Three findings are worth keeping in the plan rather than only in commit messages, because each contradicts what the entry previously assumed: - The delete-dialog reds had drifted further than recorded — not only the focused fill but the resting treatment and the label rule. - The scrim was never "one literal in four files". It was an asymmetry: five modal surfaces, only one of them scheme-derived, so a light scheme put a black veil behind a light panel. - No fixed blend strength can carry a semantic fill across all nine schemes. Nord (error, 4.42:1) and Solarized (warning used raw, 4.37:1) land at luminances where neither a near-black nor a near-white label has anything to contrast with, which is why `semantic_fill` steps the blend back until the label clears the floor. The on-device backlog gains #69 / #70 / #71, with #70 flagged as the highest-value item in the list: the scrim is the one place this work changed what an existing surface *looks like* rather than where its value comes from, and that was reasoned about, never seen. The same section now also states what the colour work *did* get machine-verified, so the distinction between measured readability and unverified appearance stays explicit. Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Happy <yesreply@happy.engineering>
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.
What
Third and last code part of the #62 follow-up (after #69 and #70): the close-window dialog's Kill/Cancel buttons, and the consent dialog's selected-button fill.
[0.75, 0.25, 0.25]danger_fill(tokens, 0.55)[0.95, 0.40, 0.40]danger_fill(tokens, 0.85)[0.95, 0.85, 0.40]caution_fill(tokens, 0.85)semantic_warningcaution_fill(tokens, 0.85)[0.10, 0.10, 0.10]fixedon_surface_text(fill)Why Kill does not reuse #70's helper
danger_button_colorsanswers "is this button focused" — it steps from a barely-tinted rest state to a mid blend, which is right for a settings delete button that only turns red once you land on it. Kill has to read as the destructive choice before it is selected, because it sits next to Cancel. So it steps from that same mid blend to a strong one. Sharing the blend and not the focused/unfocused rule is what keeps both readings intact.What the measurement changed
The labels are the substance here. A fixed near-black label is wrong on any dark fill, so labels now come from
on_surface_text(added in #69). Measuring that across all nine built-in schemes turned up something no fixed blend strength can fix:semantic_errorat 0.85semantic_warningused rawBoth are middling luminances — neither a near-black nor a near-white label has anything to contrast with. (This is also why
caution_fillblends instead of passing the token straight through.)semantic_filltherefore walks the blend back towardsurface_1until the label clearsMIN_TEXT_CONTRAST— the same shape asrow::ensure_readable. It terminates becausesurface_1derives from the scheme background, the end of the range a label can always be read against. The trade: some schemes get a slightly quieter fill than requested. An unreadable label on a destructive button is worse.The consent dialog's 3 px top stripe and its title keep the raw warning hue — a line and text, not a fill.
Test plan
cargo fmt --checkcargo clippy --all-targets -- -D warnings— clean through every cratecargo test --workspace— all pass, 0 failures (909 in this crate)mastercaution_fillto exist, and it fails on Nord if the adaptive step is removed (verified by removing it). The other pins that a stronger blend always reads as redder, since that ordering is what carries both "dangerous" and "selected"docs/plans/ui-ux-modernization-v3.md. Worth a look: whether the adaptive step-back leaves Kill visibly red enough on Nord, and the Cancel-selected fill now that it is blended rather than a flat yellowG11 follow-up after this PR
Everything the plan listed is now migrated except two items, both deliberate:
picker.rs's purple/green macro & SSH branding (its comments call it intentional — needs a product decision, not a mechanical migration) andcolor_util::resolve_color's no-palette fallbacks (unreachable outside tests, explained in #69). A plan update recording this follows separately.🤖 Generated with Claude Code