UI Design System

UI Design System

中文

Current foundation

Screen-Remote/DesignSystem.swift currently defines the small shared baseline: semantic AppTheme colors, restrained card treatment, and icon tiles. RootView.swift, SidebarView.swift, and feature pages use native SwiftUI/AppKit layout. This is not a copy of Android Compose: preserve the product's utility hierarchy while using native macOS navigation, windows, focus, and accessibility behavior.

Rules

• Tokens and shared components first: do not create a second per-page palette, radius, shadow, or spacing system.
• Use restrained hierarchy: page background, sidebar, surface, divider, primary/secondary text, and accent communicate structure; accent is for a clear action or state, not decoration.
• Prefer continuous card corners and thin dividers. Existing appCard has a 14-point default radius; change shared semantics before local pages.
• Check light/dark appearance and compact/wide window layouts for every affected family. Preserve scrolling, keyboard/focus behavior, help affordances, and accessibility labels.
• All user-visible copy, including prompts and accessibility text, enters Localizable.xcstrings; debug and protocol details remain English logs.

Product terminology

• A screen session inside Screens is a Small Window (小窗).
• The same session after expansion is a Large Window (大窗).
• Its transient functional controls and session actions are the Auxiliary Menu (辅助菜单) in both presentations.

Use the product terms first. Implementation documentation may additionally mention embedded or detached presentation, window chrome, toolbar, or control bar when that distinction is technically necessary.

Large Window Auxiliary Menu behavior

The Large Window keeps the scrcpy viewport geometry stable while the Auxiliary Menu appears or disappears. The detached window always reserves the header, bottom-control, and 8-point side-expansion geometry; changing menu visibility must not resize the NSWindow, squeeze the video, or move either video edge.

• The Auxiliary Menu uses a 0.16-second ease-out opacity transition. The standard red, yellow, and green window controls use the same duration through AppKit.
• After the pointer leaves the tracked edge regions, the menu waits 1 second before hiding.
• The top reveal region is 64 points: 32 points of header plus 32 points extending into the phone image. The bottom reveal region is 63 points: 31.5 points of bottom controls plus 31.5 points extending into the phone image. These values are interaction regions, not pure button heights. Each side also has a 10-point reveal inset.
• Hidden controls must not receive pointer input and must be hidden from accessibility until they are visible again.
• The detached container does not apply a SwiftUI outer shadow, and its native NSWindow shadow is disabled. Menu visibility therefore has no shadow effect or shadow transition to coordinate.

Page families

The sidebar/root shell, device/session workspaces, management pages, settings, dialogs, diagnostics, and empty/error states should use the same semantic levels. Management utilities must show progress, cancellation, safe error summaries, and destructive-action clarity without embedding ADB execution in views. Notifications, Messages, and Photos remain honest empty states until their data channel exists.

Change acceptance

Inspect both appearances and narrow/wide windows, test locale switching for changed copy, and ensure no text truncates or creates inaccessible controls. Use the Xcode Screen-Remote scheme with the My Mac destination only when a build/run or visual verification is warranted.