Skip to content

AcceptedOwner sparkles:terminalReviewed 2026-10-03

Design: the mockup register ​

Introduction ​

The terminal draws its own interface on every platform: the tab tree, pane headers, menus, confirmations and pages. Requirements fix what each surface does, but not how it is arranged, and an arrangement that reads well on a desktop can fail on a phone held upright or in landscape. Choosing a layout from prose alone tends to settle on the first idea written down.

Each surface's layout is therefore chosen by the repository owner from two or three HTML mockups, drawn at three sizes (phone portrait, phone landscape and desktop) and shown over dark, light and saturated terminal schemes (D10). A mockup decides arrangement, density, the shape of an affordance and motion; behaviour stays with the requirement pages, and apps/terminal implements the chosen variant.

This page registers every surface, its variants and the choice, and states the rules any variant must meet. A requirement whose layout waits on a choice has the status open, meaning undecided; once its mockup is chosen it becomes not started, meaning decided but not built, with a link to the chosen variant. Behaviour, and the design system's own tokens and rules, are out of scope here: the requirement pages and the design system own them.

Rules every variant must meet ​

From the design system and the theme, applied rather than restated:

  • Slots, not colours (THM1); each implemented component declares its slot set with a test (TOK6).
  • The chrome's colours derive from the terminal's (D17): every variant is shown over a dark and a light terminal scheme, and over one saturated Termux scheme, to prove it tracks.
  • Interaction states (TOK4/TOK5): rest, hover (desktop), focused, selected, pressed and disabled are drawn for every control.
  • Focus visible in monochrome (ACC4), and never colour alone for status (ACC3).
  • Cells are the unit (TOK7); touch targets are at least 48 dp; radius and shadow are pixel metrics with a cell projection.
  • Reduced motion (ACC5) has a defined rendering for every animation.
  • The keyboard is the program's (TKM2): no surface may assume a key the pane would lose.
  • Large screens take the desktop's arrangement (D47): on a screen at least 600 dp across, the rail stays in portrait, the selection menu is the anchored card (TCF14), and pages and sheets are at most 100 columns wide (TPG19).

Surfaces ​

Three canvases hold the variants: workspace, overlays and pages. Each artboard has a dark and light switch, and some are interactive. A chosen variant is recorded here and in decisions. Once a surface is decided, the variants it rejected are removed from the canvas; the register keeps their names (S1, S3, E2, G1, G2, C2, LG2, N1, K1, K2).

SurfaceRows it decidesVariantsChosen
Workspace: tab strip, splits, headersTSS11, TSS12, TSS13EE, opener by ui.tabsOpener, chrome by ui.paneChrome (TCF12, TCF13, D42)
Extra-keys row (and its show/hide)TCF7, TKM7EE: the row under the terminal, above the keyboard
Selection handles and the selection menuTSE3, TSE5S2, B1–B4, X1–X3all, chosen by ui.selectionMenu (TCF11); X1 on the desktop (D41)
Button labelsTCF9S2, E1, L3, D1 (Tweaks)a setting (D35)
Confirmations: anchored card or sheetTCF10CA1–CA4, CS1–CS4both, chosen by ui.overlayStyle (D41)
Link confirmTPR5L1, L2both presentations (D41)
File linkTDV12L3both presentations (D41)
Paste guardTPR19P1both presentations (D41)
OSC 52 read confirmationTPR21P2P2 (D40)
Exit promptTSS2E1, E2E1, expanding status line (D39)
Autofill chipTSE10A1A1 (D40)
Desktop context menu and link barTSE7, TPR7D1D1 (D40)
Settings pageTSP5–TSP8G1, G2, G3, G4G3, with the G4 capture editor (D36, D37)
About and credits pagesTPG1–TPG3, TPG15C1, C2C1 (D40)
Log pageTPG8LG1, LG2LG1 (D40)
Notification log, unseen marksTPG9–TPG11, TPG18N1, N2N2, with a grouping control (D38)
Touch key guideTKM6K1, K2, K3K3, search at the bottom (D40)
Viewer paneTDV5, TDV6V1, V2both: tab and split (D40)

→ Overview · Decisions