Module floating_surface
Expand description
Shared placement contract for app-bound overlays and shell-owned PiP.
Apps describe what should float; this module owns how it moves. The
same state machine is used while a surface is attached to its app and after
the shell adopts it as desktop PiP, avoiding a second set of drag/snap rules.
Structs§
- Floating
Placement - Placement + drag state shared by call, navigation, browser
PiPand arbitrary captured regions. - Floating
Surface Presentation - App-owned presentation currently living in desktop coordinates. The UI runtime uses this one read-only description both to render the secondary window and to stream placement changes to the compositor.
- Floating
Surface Protocol Request - Floating
Surface Request - Floating
Surface Service Client - Non-blocking app-side connection to the session shell. The launcher hands
the already-connected socket into the sandbox as
TILO_SVC_SHELL-UI_FD; newline-delimited JSON keeps the tiny lifecycle protocol inspectable and lets the compositor service evolve independently of app/widget releases. - History
Change Description - One change described: its id, the sentence, and which provider and model wrote it.
- History
Change Facts - What a model may know about one change it is asked to describe: the change’s id as History lists it (32 lowercase hex characters), its own summary, the action and resource it named, and what it wrote. Never who made it: History shows that beside the description.
- Host
Network Status - Sanitized host network hints. Unknown is distinct from known unmetered; this carries no connection name, device, address or network permission.
- Pointed
Control - One control of an app’s window as the shell names it when a person points at it: its semantic id, its role and its accessible name. What a field holds is never part of it.
- Recipient
- One recipient of a message sent from a window: who it goes to, and what the person reads on its chip.
Enums§
- Attachment
- Where the floating surface currently belongs.
- Capture
Studio Protocol Mode - Starting mode for an app-requested session-shell chooser. The request only opens trusted shell UI; it never grants an app capture permission or pixels.
- Device
Shell Operation - Owner-only operations on Terminal’s existing device-shell PTY. Every input/read operation is bound to the exact currently open local session.
- Floating
Role - Presentation hints understood by both app and shell hosts.
- Floating
Source - Stable identity of content that can survive an app → desktop hand-off.
- Floating
Surface Client Message - App → shell lifecycle.
Suspendis the reversible half of an attached ↔ desktop handoff: the authenticated native surface and its renderer stay warm while its pixels return to the app.Dismissis deliberately permanent and reserved for hang-up, navigation-end, or an explicit close. - Floating
Surface Host Message - Shell → app lifecycle. The shell supplies one authoritative combined desktop coordinate space and explicitly acknowledges ownership changes; transports must not infer either from timing.
- Floating
Surface Protocol Role - Roles are additive wire values: an older peer refuses an unknown role; it must never reinterpret interactive content as a capture mirror. Adding a role preserves the existing framing, geometry, and legacy role values.
- Floating
Surface Protocol Source - Handoff
- Result of updating a drag. Hosts use the edge to animate the hand-off.
- Material
- What a floating surface’s body is made of. A surface names its material;
the toolkit and compositor decide how it renders — the blur radius, the
tint and the opaque fallback are never the caller’s
(
docs/design-language.md, “Material and transparency”). - Recipient
Kind - What a recipient of a sent message is: someone the search found, or the agent the person is making by sending.
Constants§
- FLOATING_
SURFACE_ APP_ ID_ PREFIX - FLOATING_
SURFACE_ PROTOCOL_ VERSION - The app ↔ shell interface’s one version: everything an app and the
session shell say on the shell-ui connection (floating-surface
lifecycle, the window’s appearance, tabs, selection). The app’s first
frame is
FloatingSurfaceClientMessage::Hellowith this number; a shell at another number answersFloatingSurfaceHostMessage::VersionMismatchand closes, and updates whichever side is behind (docs/architecture/compatibility.md). There is no negotiation and nothing kept for an older number.interface.tomlbeside this crate holds the schema, and the repository policy fails a change to it that keeps the number. - FLOATING_
SURFACE_ SERVICE
Functions§
- app_
owned_ content_ window_ rect - The native allocation around retained interactive content, including the floating card’s frame, its edge and the themed elevation. Content geometry stays unchanged: the extra pixels are a transparent frame gutter, not padding inserted into the app’s layout or input coordinates.
- paint_
app_ owned_ content - Paint the framework-owned frame around one interactive app-owned surface (an app’s call or navigation card).
- paint_
material - Paint a floating surface’s body:
shapefilled withmaterial. Edges, shadows and content are drawn by the caller on top, exactly as on an opaque surface. - protocol_
input_ rect - Validate optional interactive geometry without enlarging the native window.
- protocol_
rect - Convert protocol coordinates into a validated rectangle.
- protocol_
rect_ array - snap_
to_ edges rectmoved onto an edge ofboundsit stands within 32 px of,gapin from it: the settle every floating thing uses, cards and windows alike.- translate_
input_ rect - Move a declared interactive region with its host geometry.