Every design system ships with the same premise — make it clean, make it accessible, make it feel like a SaaS product from 2024. Rounded corners, system fonts, 4px border-radius, blue primary buttons. The result might not be bad design. It might be no design — a thousand applications wearing the same face.
The terminal’s honesty
The terminal might be the most honest interface ever built. Monospace type aligns perfectly. Borders are characters. Color is functional, not decorative. Nothing is rounded because nothing needs to pretend it’s friendly. The aesthetic wasn’t designed — it emerged from constraint. That might be why it works.
Doomslayer-UI starts from this assumption and builds a complete design system on top of it. Seven terminal color themes — default (WeeChat dark), solarized, nord, dracula, monokai, ayu-dark, and ayu-light. Seventeen components covering layout, controls, and data display. One singleton that holds all tokens. Switch themes at runtime with a single call. Every component reacts. No rebuild, no restart.
Components as characters
DSButton renders with [brackets] in primary, danger, and disabled states — the visual language of a command-line prompt. DSSectionTitle uses box-drawing characters: ├─ Title ─. DSProgressBar fills with block characters: ████░░░░. DSTable alternates row backgrounds and highlights on hover. DSConsole renders terminal log output with the formatting you’d expect from an actual terminal emulator.
The API surface is the singleton. DSTheme.bg, DSTheme.fg, DSTheme.red through DSTheme.cyan. Semantic aliases — DSTheme.error, DSTheme.success, DSTheme.primary. Typography defaults to Menlo at five sizes. Spacing tokens from 2 to 16 pixels. The design system makes visual consistency automatic instead of aspirational.
Testing the idea in practice
A design system that only exists in a component library is a proposal. A design system applied to a real product is a proof. Doomslayer-Basecamp is the proof — the entire Logos Basecamp desktop application reskinned with Doomslayer-UI. Every view, every plugin, every widget running through the terminal aesthetic. C++ compiled QPalette changes at the host level. QML theme injection into every loaded plugin. File-based sync so plugins poll the active theme and stay current.
The user sees one application, not a host with mismatched plugins. That might be the test of a design system — not whether it looks good in isolation, but whether it can hold coherence across a real product with real plugins written by different teams at different times.
What the aesthetic refuses
The question behind any aesthetic choice might be: what does this refuse? Rounded corners refuse nothing. They’re the absence of a decision. The terminal aesthetic refuses decoration, refuses friendliness, refuses the assumption that the user needs to be reassured. It treats the user as someone who’s here to do something, not to be entertained while doing it.
That refusal might be the design. Still testing whether it holds.