feat(ui): add borderless chrome mode#481
Conversation
Replace drawn borders and separators with filled background bands derived from the active theme. Add a theme surface elevation ladder (code, contextBand, sidebar, sectionHeader, overlay, note, selection) so file headers, the unchanged-lines band, popups, and comment boxes stay visually distinct without lines. Route chrome through chromeSurfaceBg/overlaySurfaceStyle helpers and a ChromeSeparator primitive; the divider reveals an accent rule only while resizing. Toggle via the View menu, the borderless config key, or --borderless. A surfaces test asserts adjacent ladder levels stay distinct across every bundled theme.
|
PR author is not in the allowed authors list. |
|
I feel like this is a lot of code to support a fringe case. I'll keep open, but ... my initial instinct is it's not worth the complexity. In the video, it doesn't feel like it makes a sufficiently big difference (space wise). |
|
fair enough, @benvinegar this is something I personally wanted tbh, and I thought I’d share it upstream since I worked on it definitely your call, no hard feelings at all if you discard it thanks! |
|
Yeah it's just a question of - do we want like ~500 lines of code dedicated to making this happen, for whom I don't know how many users are on the other side. Is there a way we could do this so it's less one-off and people can just customize elements of the UI broadly? I'd find that more compelling, but certainly a deeper dive. |
|
@benvinegar thought about this, totally agree the binary flag is too narrow but I think the guts are flexible enough to apply other use cases, what's already in the PR is a small per-theme surface system: each theme derives an elevation ladder ( graph TD
theme[theme palette] --> ladder[ChromeSurfaces<br/>elevation ladder]
ladder --> prims[chrome primitives<br/>chromeSurfaceBg / overlaySurfaceStyle<br/>railGlyph / ChromeSeparator]
prims --> comps[menu bar · status bar · headers<br/>sidebar · rails · popups · comment cards]
flag[--borderless<br/>on / off] --> prims
so what you're describing — letting people customize chrome more broadly — is basically the layer i already built, minus the one-off flag. i'd rework it to expose the choice as a theme/config primitive (e.g. graph TD
cfg[chrome.style<br/>bordered · banded · ...] --> prims[chrome primitives]
theme[theme palette] --> ladder[ChromeSurfaces ladder]
ladder --> prims
prims --> comps[all chrome components]
cfg -.->|room to grow| more[more presets /<br/>per-element overrides]
so the same primitives would back more than borderless — e.g
happy to take a swing at that framing if it sounds worth it — otherwise no worries at all, i'll keep it in my fork. |
What
Adds an opt-in "borderless" chrome mode that replaces drawn borders and
separators with filled background bands derived from the active theme. The diff
still reads as distinct regions — file headers, the unchanged-lines band,
sidebar, popups, and comment boxes — but through layered surfaces instead of
lines, for a cleaner, modern look.
Bordered chrome remains the default; nothing changes unless you opt in.
How to toggle
--borderless/--no-borderlessCLI flagsborderlessconfig keyShift+Bkeybinding (listed in the?help)Demo
2026.06.23.17.11.19.mp4
How it works
Each theme gains a derived surface elevation ladder (
ChromeSurfaces)mapped from its existing semantic palette (editor / panel / titlebar tokens), so
authored themes look native and adjacent levels stay visually distinct. A small
set of primitives centralizes the border-vs-band decision so the choice never
scatters across components:
chromeSurfaceBg(theme, level)— resolve a surface background by ladder leveloverlaySurfaceStyle(theme)— bordered box vs filled band for popups/dialogsrailGlyph(theme)/ChromeSeparator— diff rails and separatorsTouched chrome: menu bar, status bar, file-section headers, sidebar, diff rails,
menus/dialogs/popups, agent comment cards, and the pane divider (which still
reveals a rule while dragging to resize).
Tests
on every bundled theme
Shift+Bstays out of the page-up alias)