Future Shell Appearance (Long-Term)

**Long-term planning only.** Not scheduled for the current product loop. Do not treat this file as a design constitution or as permission to change shell visual

Status

Long-term planning only. Not scheduled for the current product loop. Do not treat this file as a design constitution or as permission to change shell visuals before an explicit, scoped implementation task.

Canonical design rules today remain in docs/product/design/DESIGN.md and linked shell/app design language docs. This roadmap note records intent and sequencing only.

Product intent (non-binding)

Explore optional shell personalization beyond today’s theme, density, and gradient background presets:

Desktop wallpaper — user-chosen or curated images on the desktop scene (likely earlier than full chrome dialects).
Visual language presets — OS-level chrome dialects inspired by different UI traditions (e.g. flatter “taskbar-like” vs more elevated “material-like” surfaces), without cloning trademark Windows / macOS / Material UI chrome.

Names in planning should stay product-owned (e.g. prox, flat-chrome, elevated-chrome), not “Windows mode” / “Material mode” in user-facing copy.

Application model

Page refresh is acceptable when switching wallpaper or visual language. Instant hot-swap across every open window and iframe is not a requirement for v1 of these features.
Persist choices in existing shell preference storage (localStorage keys under prox-os.os.*, surfaced in Display options) and apply on next load via root data-os-* attributes on <html>.
Iframe and external apps do not automatically follow shell visual language; they may continue to use default tokens inside their own document unless explicitly bridged later.

Sequencing (relative priority)

Track	Rough priority	Scope
Wallpaper	Sooner (still post–core demo stability)	Image or asset on desktop scene; respect `--os-desktop-background` and existing `data-os-background` presets where possible; Display options UX
Token-level chrome presets	Later	Second dimension on tokens: radii, shadows, border weight, accent saturation under e.g. `data-os-visual-language`
Structural chrome variants	Much later	Layout branches in `@prox-os/os-ui` (`WindowFrame`, `RuntimeCommandStrip`, `Dock`, titlebar controls)
Shell orchestration parity	Much later	Mission Control thumbnails, snap overlays, and other `apps/os-shell` surfaces aligned per language
Third-party app follow	Optional / long-tail	`packages/apps/system-apps` stay token-neutral unless an app opts in; Theme API (platform v0.4) may expose read-only hints

Current reuse baseline (observation, 2026)

Use this when estimating effort; re-validate before implementation.

Layer	Readiness	Notes
`@prox-os/design-tokens` (`prox.css`)	Strong	Central `--os-*` variables; `data-os-theme`, `data-os-density`, `data-os-background` already wired
`@prox-os/os-ui`	Moderate	~30 presentational shell components; mostly `var(--os-*)`; few hardcoded hex values
`apps/os-shell` settings	Moderate	Display options + `useShellSettingsState` already set root `data-os-*` datasets
Multi–visual-language	Weak	No `data-os-visual-language` (or equivalent); shell code assumes one Próx chrome grammar
`packages/apps/system-apps`	Weak binding	Weak design domain — tokens yes, full chrome mimicry no
Iframe apps	None	Independent origins and CSS

Summary: palette / density / wallpaper-style changes fit the existing pipeline; dialect switches that change layout and control placement are a large, multi-phase program (platform L–XL), not a single toggle.

Suggested technical direction (when implemented)

Add data-os-visual-language (name TBD) alongside existing data-os-theme / data-os-density / data-os-background.
Keep overrides in packages/ui/design-tokens/css/prox.css (or scoped override files imported there) — stable --os-* names, different values per language.
Introduce os-ui variants only where tokens cannot express layout (titlebar control order, dock geometry).
Extend Storybook / UI Workshop with one story set per language; screenshot baselines per language.
Feature-flag experimental languages in Developer Tools or Display options until stable.

Phased delivery sketch

Phase A — Wallpaper (product)
  - Curated library + optional custom URL/upload (policy TBD)
  - Persist; apply on load; optional refresh to apply globally

Phase B — Token presets (engineering)
  - 2–3 visual languages as CSS overrides only
  - Display options or dev flag; refresh to apply

Phase C — os-ui structural variants (engineering + design)
  - Window/shell chrome layout per language
  - Mission Control / snap polish per language

Phase D — Platform Theme API (v0.4+)
  - Apps read shell language hints; no requirement to restyle interiors

Current tokens and variants: docs/product/design/tokens.md, @prox-os/design-tokens
Current shell visual rules: docs/product/design/os-shell-design-language.md
Display options / startup: docs/platform/architecture/apps/os-apps.md, docs/development/ai/protocols/os-startup-flow.md
Platform Theme API placeholder: docs/product/roadmap/product/product-roadmap.md (v0.4), docs/product/roadmap/platform/platform-roadmap.md
Legacy checklist: docs/product/roadmap/product/prox-os-roadmap.md (theme/density presets bullet)

Anti-goals

Do not rewrite docs/product/design/* to describe unbuilt languages as shipped behavior.
Do not block current Próx shell design work on multi-language chrome.
Do not promise iframe apps or App Store catalog tiles will fully restyle with the shell.

Future Shell Appearance (Long-Term)

On this page