Skip to content

UI Design System

星冉 edited this page Jul 22, 2026 · 2 revisions

UI Design System

中文

This page defines the Compose visual and layout baseline for Screen Remote. The project keeps Android interaction and window structures while adopting the density, grayscale, corners, and hierarchy of iOS-style utility interfaces. Tokens and shared components are authoritative; external prototypes are not copied pixel for pixel.

Authoritative code

  • core/common/constants/CoreUiConstants.kt: IosDesignTokens, AppDimens, and AppTextSizes.
  • core/designsystem/component/: shared dialog, section, selector, and dropdown primitives.
  • feature/session/ui/component/SessionDialogRows.kt: session form rows.
  • feature/session/ui/component/SessionDialogTextFields.kt: session input rows.
  • feature/settings/ui/SettingsComponents.kt: settings sections and rows.
  • core/designsystem/theme/Color.kt and core/common/constants/AppColors.kt: light and dark semantic color levels.
  • feature/session/ui/SessionManagementScaffold.kt: shared management card, control, top-bar, and drawer specifications.
  • feature/session/ui/SessionManagementTerminalTheme.kt: the terminal's fixed dark palette.

Values in this page explain the current design; they do not replace code constants.

Design principles

  • Utility first: express hierarchy through spacing, grayscale, and dividers instead of strong shadows or decoration.
  • Tokens first: pages must not create a second system of corners, colors, spacing, or type sizes.
  • Shared shells first: windows use DialogPage, DialogContainer, and DialogHeader; lists use the existing section/card/row structures.
  • Verify both themes: inspect every visual change in light and dark mode.
  • Preserve Android semantics: iOS styling must not weaken back behavior, scrolling, keyboard avoidance, accessibility, or existing help affordances.

Current token baseline

Meaning Current value
Form row 40.dp
Dialog header 50.dp
Dialog corner 8.dp
Card corner 12.dp
Management compact control height / corner 38.dp / 18.dp
Compact/standard horizontal padding 10.dp / 16.dp
Compact/standard spacing 12.dp / 16.dp
Divider alpha 0.3f
Title/body/caption size 17sp / 15sp / 13sp

Add a token only when it carries cross-page meaning. A parameter used by one component should remain near that component.

Color hierarchy

Level Light mode Dark mode
Page and ordinary dialog background #F5F5F5 #121212
Cards and grouped boxes #FFFFFF #1E1E1E
Dialog header #FFFFFF #1E1E1E
Higher overlay / alert #FFFFFF #2C2C2E
Highest container #E9E9EE #3A3A3C
Primary text #1C1C1E #F2F2F7
Secondary text #6E6E73 #AEAEB2
  • On Settings, labels such as General and ADB Management sit on the page background; the rounded box below each label that contains multiple rows is the card level. Ordinary dialog headers and cards use the same surface color, while the outer window keeps the page background; keep the structural levels distinct when reviewing UI.
  • Light cards remain pure white #FFFFFF. Hierarchy comes from the #F5F5F5 outer background, restrained shadow, and dividers rather than making cards gray-white.
  • Dark cards remain #1E1E1E; ordinary page background is #121212, while alerts and high overlays use the brighter dark gray.
  • surfaceVariant and translucent accents are for selection, status, inputs, or compact action controls, not ordinary card backgrounds.

Component and layout rules

Dialogs, sections, and cards

  • Center titles and keep stable widths for the two action slots.
  • Content may scroll. Small screens adapt by shrinking width and scrolling, not by compressing core control heights.
  • Cards use restrained backgrounds and light dividers; section titles only communicate grouping.
  • Use the DialogPage family for ordinary windows and the appropriate alert component for warnings.
  • Ordinary dialogs use an 8.dp outer corner. The alert's 22.dp, pill 999.dp, and small icon-tile corners are explicit semantic exceptions and do not redefine the card baseline.
  • Settings groups, sections inside Edit Session, ordinary management cards, and management top cards use 12.dp.
  • USB device windows use DialogContainer, DialogHeader, shared content padding, and consistent refresh, loading, and empty-state structures instead of a private header implementation.

Form rows

Different interaction types require different width models:

  • Input row: the editor consumes remaining width and keeps end padding so a right-aligned cursor does not cover the final character.
  • Switch row: reserve only fixed switch space on the right and let the left title use the remainder.
  • Selection row: use a stable value area, group the value with its icon, and keep internal padding.
  • A title and its help icon form one content group; the icon follows the text rather than the container edge.

These are the durable conclusions from the former Edit Session Dialog layout notes; the one-off fix narrative is no longer maintained separately.

Compact density is an explicit current choice: Settings items and Edit Session form rows remain 40.dp. Management search fields, command input, and compact action buttons use a 38.dp height and 18.dp corner. Do not expand them back to the 48.dp Material default automatically, and do not apply the management-control height to Settings form rows.

Page families

  • Home session cards: 120.dp high, 12.dp corner, 2.dp shadow, 16.dp page horizontal padding, and 16.dp card spacing. Colored cards express Home identity and do not replace theme semantic colors.
  • Settings and Edit Session: use DialogPage, SectionCard, and shared rows. Settings cards and sections inside Edit Session both use 12.dp; form rows remain 40.dp.
  • Management: the shared page frame occupies 98% of the window width; its detail content occupies 95% of the window and shares the top row inside that frame. The frame clips its bottom corners to 12.dp. Ordinary and top cards use SessionManagementCardShape (12.dp). Search and action controls use SessionManagementControlHeight (38.dp) and SessionManagementControlShape (18.dp). Status badges and pills are exempt from this corner rule.
  • Shadows distinguish hierarchy rather than decorate: Settings cards normally use 0.5.dp, ordinary management cards are flat (0.dp) inside the shared frame, Home session cards use 2.dp, and overlays such as the drawer may use more.

Terminal exception

The management terminal uses the fixed dark background #18181A under both light and dark app themes so command output contrast and semantic highlighting remain stable. Error, warning, success, match, number, string, and path colors come from SessionManagementTerminalTheme.kt. The terminal's outer surface still follows the management-card 12.dp corner. This is an intentional theme exception and its colors must not be copied to other management pages.

Color and typography

  • Page, dialog, header, card, and divider levels must be distinct but restrained.
  • Use accent color only for clear actions or states, not large decorative areas.
  • Prefer MaterialTheme and project tokens; feature pages must not hard-code colors.
  • User-visible strings come from bilingual text objects; see Bilingual Text and Copy.

Change and acceptance flow

  1. Change a token or shared component before changing individual pages.
  2. Inspect affected session editing, settings, pairing, management, and selector screens.
  3. Verify light mode, dark mode, small screens, and the keyboard-visible state.
  4. Confirm there is no premature truncation, edge crowding, asymmetric action slot, or reduced touch target.
  5. Run compilation and relevant Compose/state tests for visual changes.
  6. Verify the actual level being changed: page, dialog, header, card, control, badge, and terminal must not be collapsed into one generic “box.”

Directions to avoid

  • Copying a local set of dp, sp, colors, and corners into a page.
  • Adding a page-specific wrapper that duplicates an existing component.
  • Converting every dialog into a full-screen navigation page.
  • Treating a fixed-pixel screenshot as the only acceptance criterion across devices.

Related: Session Parameter Selectors, Remote Interaction Performance and Floating Menu, and Engineering and Verification Rules.

Clone this wiki locally