Prox OS Internal Docs
PlatformArchitectureSpaces

Desktop Grid Model

This document defines the responsive desktop grid direction for Prox OS. It

Status

This document defines the responsive desktop grid direction for Prox OS. It does not implement a new desktop grid UI, route model, database schema, or drag/drop persistence.

Purpose

Prox OS runs inside the browser. The desktop surface can be resized at any time by browser chrome, device rotation, embedded contexts, side panels, Alma, the Dock, or shell overlays. Desktop items and windows therefore cannot depend on absolute native-OS pixels as their source of truth.

Core Principles

  • Desktop items should use responsive grid coordinates, not fixed pixels.
  • Window geometry may use normalized coordinates plus min/max constraints.
  • Browser resize must clamp windows and desktop items into visible safe areas.
  • Top bar, Dock, sidebar, Alma, drawers, and panels must be treated as safe areas.
  • Small screens may enter single-window or maximized-first mode.
  • Advanced free placement should come after a stable grid and safe-area model.

Desktop Item Layout

Desktop items should be modeled as grid placements within a Space.

Conceptual shape:

type DesktopItemLayout = {
  spaceId: string
  itemId: string
  col: number
  row: number
  colSpan: number
  rowSpan: number
  order: number
}

The source of truth is the logical grid position, not the last rendered pixel position. Pixel positions are derived from the active desktop container size, safe areas, density, and item size rules.

Window Geometry

Window geometry can keep runtime pixels while the current shell is local-only, but persistent or cross-device state should move toward normalized geometry.

Conceptual shape:

type WindowGeometry = {
  xRatio: number
  yRatio: number
  widthRatio: number
  heightRatio: number
  minWidth: number
  minHeight: number
  maxWidth?: number
  maxHeight?: number
}

When restoring a window, the shell can derive pixel geometry from the current workspace bounds and then clamp it. App manifests can provide size hints, but the shell owns final geometry.

Safe Areas

Safe areas are shell-owned layout exclusions:

  • RuntimeCommandStrip / top bar.
  • Dock.
  • Alma or sidebar.
  • Utility trays.
  • Floating command surfaces.
  • System overlays.
  • Mobile browser viewport constraints.

Windows and desktop items should avoid ending up under persistent chrome. Transient overlays can appear above them, but resize and restore logic should still keep primary controls reachable.

Resize Strategy

When the desktop container width or height changes:

  1. Recompute available columns and rows from the container, density, safe areas, and minimum item size.
  2. Keep grid items in their logical order.
  3. Clamp visible items into the available grid.
  4. Move items outside the current visible grid into a future page, wrap region, or overflow folder.
  5. Recompute window pixel geometry from normalized geometry when available.
  6. Clamp every window into the visible safe area.
  7. Prefer maximized-first or single-window mode on narrow screens.

Windows should never become unreachable after resize. At minimum, each restored window must keep a reachable titlebar and close/minimize/fullscreen controls.

Current Phase Constraints

The current shell can start with auto-arranged desktop items, folders, and window clamping. Full freeform desktop placement, persistent responsive grid editing, and cross-device layout sync should be separate implementation tasks.

Do not introduce a large desktop grid rewrite just to support one feature. New Space or desktop work should document whether it touches item layout, window geometry, safe areas, or persistence.

Relationship With Spaces

Desktop item layout belongs to a Space. A user switching Spaces should see a different desktop item set, widget set, and window layout memory. A future Space can also store a default window group preset; see Window Group Layout Presets.

On this page