Skip to content

feat(ui): add borderless chrome mode#481

Open
eduwass wants to merge 1 commit into
modem-dev:mainfrom
eduwass:feat/borderless-chrome
Open

feat(ui): add borderless chrome mode#481
eduwass wants to merge 1 commit into
modem-dev:mainfrom
eduwass:feat/borderless-chrome

Conversation

@eduwass

@eduwass eduwass commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

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-borderless CLI flags
  • borderless config key
  • View → Borderless chrome menu entry
  • Shift+B keybinding (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 level
  • overlaySurfaceStyle(theme) — bordered box vs filled band for popups/dialogs
  • railGlyph(theme) / ChromeSeparator — diff rails and separators

Touched 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

  • Cross-theme guardrail asserting adjacent surface levels stay distinguishable
    on every bundled theme
  • Keybinding guard (Shift+B stays out of the page-up alias)
  • Updated menu/help dialog coverage

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.
@greptile-apps

greptile-apps Bot commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

PR author is not in the allowed authors list.

@benvinegar

Copy link
Copy Markdown
Member

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).

@eduwass

eduwass commented Jun 29, 2026

Copy link
Copy Markdown
Contributor Author

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!

@benvinegar

Copy link
Copy Markdown
Member

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.

@eduwass

eduwass commented Jun 29, 2026

Copy link
Copy Markdown
Contributor Author

@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 (ChromeSurfaces) from its existing palette, and a handful of primitives centralize the border-vs-band decision in one place instead of scattering it across components. --borderless is just a binary switch flipped on top of that:

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
Loading

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. chrome.style = "bordered" | "banded", settable per-theme and overridable in config), with borderless dropping out as just one value. that kills the one-off, keeps the maintained surface small, and leaves room to grow into the broader customization you'd find more compelling:

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]
Loading

so the same primitives would back more than borderless — e.g

  • a compact value that drops separators/thins rails (actually moves the space needle, unlike borderless alone)
  • themes shipping their own bordered/banded default
  • configurable rail glyphs for nerd-font vs ascii terminals
  • etc

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants