fix(tui): restore foreground hue step for tab status colors - #49899
Merged
Merged
Conversation
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
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.
Why
In dark mode the session tab rail's running spinner, unread marker, and
!/?attention markers render in a near-background shade, so a busy tab shows a barely visible flickering dot instead of a spinner. The/btwspinner and mini-mode status colors have the same problem.Two theme refactors landed today a few hours apart. #49820 flipped hue steps to follow the mode's contrast direction, so in dark themes
100is now the light end and800the dark end, and it moved thetext.status.*tokens from.800to.200accordingly. #49846 then removedtext.status.*and rewrote its consumers as raw hue lookups, but used the pre-flip step[800]:The dialogs converted in the same commit correctly use
[200]; these call sites were the stragglers.What Changes
Every
theme.hue.accent[800]/theme.hue.interactive[800]status color moves to step200, matching how the theme asset defines every other foreground token (text.base,text.feedback.*,text.formfield.*are all$hue.*.200). Light mode is unaffected in intent: its hue ramps are inverted inopencode.json, so200is the high-contrast foreground step in both modes.accent[800]→#271640on#141414accent[200]→#9d7cd8•and glow hueinteractive[800]→#3d1d06interactive[200]→#fab283!/?attentioninteractive[800]interactive[200]/btwspinneraccent[800]accent[200]running/question/permissionaccent[800]/interactive[800]accent[200]/interactive[200]Demo
Both halves run the identical Drive script (dark
opencodetheme, vertical tabs, 120×30, simulated model streaming a slow reply so the session stays busy). Left:origin/v2at7125f5f. Right: this branch. Cropped to the left 600px of each frame so the tab rail stays legible side by side.tab-status-demo.mp4
Zoomed tab rail from the same runs — top is before, bottom is after:
Scope
Only the hue step at the call sites #49846 converted, plus the two tests that asserted on
[800]. No theme schema or asset changes. Whether these should return to a semantictext.statustoken is a separate question for the theme work in flight.Verification
End to end: the Drive before/after recording above, run against
7125f5fand this branch with the same script.