Repository navigation
feat(theme): lay out migrated V1 themes on opencode2 steps under new designs - #59996
Conversation
There was a problem hiding this comment.
Works as described. With new-designs on, tokyonight's command palette shows a quiet tint on the selected row instead of the vivid primary bar, and the raised surfaces separate from the page (before/after below). The theme and TUI theme tests pass, and tsc reports no errors in either package.
Public API: unchanged. migrateV1 and parseTheme gain an optional { newDesigns } argument, and existing callers behave as before.
One concern, see the inline comment: under new designs, a transparent V1 background becomes a solid colour. This affects the built-in system theme and any theme with background: "none".
| scale[step] = oklchToHex(color) | ||
| } | ||
| lightness[900] = pageLightness | ||
| scale[900] = opaque(theme.background) ? hex(theme.background) : oklchToHex({ ...surfaceTint[900], l: pageLightness }) |
There was a problem hiding this comment.
When theme.background is transparent, step 900 gets a generated solid colour. That makes background.base solid under new designs. This affects the system theme (its background is the terminal colour with alpha 0) and any V1 theme with background: "none". I checked with generateSystem and a terminal background of #101010: background.base is alpha 0 with the flag off but solid #121212 with newDesigns. tokyonight with background: "none" gives transparent vs #111322. So the page no longer shows the terminal's own background, and it can visibly differ from it.
The current migration keeps the transparent value, so it would be good to keep hex(theme.background) at 900 here too and use pageColor only to work out the other steps and the contrast.
…keep transparent surfaces
There was a problem hiding this comment.
The transparency point is fixed: under new designs, transparent V1 surfaces now stay transparent. I checked the system theme and tokyonight with background: "none", and both keep a transparent page. The selected row in the command palette still looks as described with tokyonight. Theme tests pass and tsc reports no errors in either package. Nothing new to raise.
Public API: @opencode/theme/tui adds a migrateV1NewDesigns export, and parseTheme takes an optional { newDesigns } argument. Both are backwards compatible.



Issue for this PR
Closes #
Type of change
What does this PR do?
With the
new-designsexperiment on, the new components expect hue steps laid out likeopencode2: text on neutral 100/200/300, the page on 900, raised surfaces on 700/600/500, the vivid color on 400, and a quiet tint on 600 for the focused row. Migrated V1 themes still used the old layout (vivid color on 200, page on 800). So under the experiment they got a vivid selected row and surfaces that barely separate from the page.A new
migrateV1NewDesignsinpackages/theme/src/tui/v1-migrate-new-designs.tshandles the experiment.v1-migrate.tsonly exports the helpers it shares, and its output is unchanged. The new migration:opencode2. Only lightness and chroma come from opencode2; hue and tint come from the V1 theme.opencode2.background,backgroundPanel,backgroundElement) stay transparent, so transparent themes still show the terminal through.parseThemein the TUI picksmigrateV1NewDesignsormigrateV1based on the experiment flag and caches each result separately.How did you verify your code works?
packages/tui/test/theme/v2/v1-migrate.test.ts:bun testfor the theme package and the TUI theme/mini suites, plustscfor both packages.opencode2in dark and light mode, using headless OpenCode Drive screenshots of a session and the session picker.Text contrast on the selected row (dark): tokyonight 5.4 → 8.1, catppuccin 5.2 → 8.0, gruvbox 4.7 → 7.5, everforest 3.1 → 5.2.
Screenshots / recordings
To be attached.
Checklist
Added by the opencode bot (AI-generated).
Public API: adds migrateV1NewDesigns to @opencode/theme/tui (backwards compatible)