feat: integrate native applications into tiled and focused workspaces
Outcome
Place native applications beside generated AOS activities in the same tiled and focused workspace without pretending native windows are A2UI components.
No proving application or host backend is selected. Steam through Gamescope/XWayland may appear only as a non-binding illustrative compatibility example or falsifier. It does not bind AOS or Astrid architecture, and it is not the first proving pair.
Scope and ownership
AOS owns the outer NativePortal only: lifecycle, readiness, placement, layout, framing, outer portal chrome theme, focus and input handoff, fullscreen, failure and degraded state, and recipe restore intent. Application interiors stay unchanged. AOS does not acquire pid or window authority, persist live handles, theme or repaint application content, or represent that content as A2UI components.
The NativePortal consumer contract is private: no public WIT or guest-visible host path is required or authorized. OwnerVolumePortal remains storage, not a graphical portal. Hosted graphics, Realm process control, and the Astrid compositor remain OS-owned.
A named proving pair is still required before implementation or an Astrid #1714 private-contract freeze. That pair must be one actual graphical application and one host backend, with observable launch, presentable-surface readiness, explicit focus acquire and release, input only while focused, teardown drain, and crash as unavailable or relaunch. Until AOS #97 and astrid-runtime/astrid#1707 deliberately name that pair, this issue stays parked.
The recipe stores restore intent: app identity, portal contract, durable activity descriptor, and restore policy. It never stores pid, window id, live handle, argv snapshot, or environment.
Dependencies
- Parent epic #89.
- #91 Surface Model: native applications are portal nodes, not A2UI components.
- #92 detached shell tiling, focus, and NativePortal placeholder interaction.
- #93 outer portal chrome theme tokens only; never application interiors.
- #94 recipe persistence of native restore intent, never live handles.
- astrid-runtime/astrid#1714 private native portal authority. Presentation is not authority. #1714 must not freeze until #97 and #1707 name a real application and host backend.
- astrid-runtime/astrid#1707 private principal-scoped Linux Realm surfaces. #1707 remains a generic surface decision until it names the same proving pair.
- #1710 owner and projection freeze for any durable native activity owner citations.
Exit gate
A user can launch, tile, focus, move, close, and restore named native applications alongside generated surfaces; pointer and keyboard focus cannot cross authority boundaries; application failure does not corrupt the workspace recipe; unsupported capabilities degrade honestly; restore uses recipe intent, never pid or window handles.
This gate cannot be claimed until #97 and #1707 name one actual graphical application and host backend.
Claim boundary
This does not prove universal Linux compatibility, GPU or driver parity, native Astrid drivers, untrusted Linux drivers, Gamescope or XWayland as a class, Steam compatibility as a class, or that arbitrary application content is trusted. It does not authorize pid or window authority, persisted live handles, theming application interiors, embedding native windows as A2UI, a public WIT change, or treating presentation as capability.
An illustrative Steam or Gamescope example is not a selected consumer and confers no architecture freeze.
Verification
Once a proving pair is named: launch to presentable-surface readiness; explicit focus acquire and release; input isolation while unfocused and across principals; fullscreen and focus transition; teardown drain; crash, unavailable, and relaunch; recipe restore of intent without pid, window, or live handle; missing-backend degradation; accessibility of the outer portal chrome only; no theme or repaint of application interiors; no A2UI mapping of native widgets; no public WIT or guest-visible host path. Until then, only generic NativePortal and recipe-intent fixtures apply.
Source: unicity-aos/aos-ce