Repository navigation
fix: drop the palette combination that looked unthemed - #39
Merged
Merged
Conversation
A screenshot made it obvious: one worktree read as clearly coloured, the other as barely touched. The dull, dark quarter of the palette (saturation 0.42, lightness 0.22) sits ΔE 22 from VS Code's default dark chrome — close enough to pass for an unthemed window. Every colour here is dark because white text has to stay readable on it, and the default chrome is dark too, so the two can drift close. That is the constraint; the fix is to not use the corner of the space where they meet. Three combinations instead of four. Worst case against the default rises to 27, WCAG holds at 4.53:1, and distinctness between worktrees is unchanged at seven percent collisions among four. The property had no test, which is why the palette shipped with it. It does now: reintroducing the fourth combination fails at ΔE 22. Existing worktrees will change colour the next time they are themed.
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.
A screenshot made it obvious: one worktree read as clearly coloured, the other as barely touched.
The dull, dark quarter of the palette — saturation 0.42, lightness 0.22 — sits ΔE 22 from VS Code default dark chrome. Close enough to pass for an unthemed window.
That is the inherent tension: every colour has to be dark because white text must stay readable on it, and the default chrome is dark too. The fix is not to widen the space but to stop using the corner where the two meet.
Distinctness costs nothing; visibility improves.
The property had no test
Which is why the palette shipped with it. Every existing test measured worktrees against each other; none measured them against no colour at all. Reintroducing the fourth combination now fails at ΔE 22.
Note
Existing worktrees change colour the next time
gwt addorgwt openthemes them.feature-agoes from#213f50to#16425a.163 tests.