makepad/widgets/themes
Admin a8bf0e4dcf wm on Android: every app is its own process -- the plain makepad-wm now ships as an Android APK (cargo makepad android ... proc-pack -p makepad-wm-android) whose phone apps run as real child processes instead of dylibs loaded into the WM. The interface between WM and app shrinks to what the desktop WM uses: shared GPU buffers and the StudioToApp/AppToStudio protocol. The WM allocates each app's swapchain as AHardwareBuffers and hands them over a unix socket (AHardwareBuffer_sendHandleToUnixSocket, API 26); the child, started through the libmakepad_launch.so launcher in nativeLibraryDir (W^X allows it there), imports them into a windowless Vulkan device and renders its window pass into them (android_hosted.rs). Each app library links the engine statically, so the engine-dylib identity handling of wm-dyn is not needed. Children have no JVM: assets are read from the APK file, audio device lookup no longer goes through Java, and the startup/resize extra draw of the Activity build is repeated so the first frame carries its text. On a phone the WM asks for the soft keyboard only while the child reports a focused text field. Proven on a Pixel 11 Pro XL: all twelve phone apps launch as processes (first frame 1.6-2.4 s cold), taps reach them. Not yet: HTTP in children (the Activity build borrows Java's), clipboard/permission/file-picker relays, idle-app reclaim, and on-device builds of app libraries
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-23 22:34:44 +02:00
..
android wm on Android: every app is its own process -- the plain makepad-wm now ships as an Android APK (cargo makepad android ... proc-pack -p makepad-wm-android) whose phone apps run as real child processes instead of dylibs loaded into the WM. The interface between WM and app shrinks to what the desktop WM uses: shared GPU buffers and the StudioToApp/AppToStudio protocol. The WM allocates each app's swapchain as AHardwareBuffers and hands them over a unix socket (AHardwareBuffer_sendHandleToUnixSocket, API 26); the child, started through the libmakepad_launch.so launcher in nativeLibraryDir (W^X allows it there), imports them into a windowless Vulkan device and renders its window pass into them (android_hosted.rs). Each app library links the engine statically, so the engine-dylib identity handling of wm-dyn is not needed. Children have no JVM: assets are read from the APK file, audio device lookup no longer goes through Java, and the startup/resize extra draw of the Activity build is repeated so the first frame carries its text. On a phone the WM asks for the soft keyboard only while the child reports a focused text field. Proven on a Pixel 11 Pro XL: all twelve phone apps launch as processes (first frame 1.6-2.4 s cold), taps reach them. Not yet: HTTP in children (the Activity build borrows Java's), clipboard/permission/file-picker relays, idle-app reclaim, and on-device builds of app libraries 2026-09-23 22:34:44 +02:00
android-dark wm on Android: every app is its own process -- the plain makepad-wm now ships as an Android APK (cargo makepad android ... proc-pack -p makepad-wm-android) whose phone apps run as real child processes instead of dylibs loaded into the WM. The interface between WM and app shrinks to what the desktop WM uses: shared GPU buffers and the StudioToApp/AppToStudio protocol. The WM allocates each app's swapchain as AHardwareBuffers and hands them over a unix socket (AHardwareBuffer_sendHandleToUnixSocket, API 26); the child, started through the libmakepad_launch.so launcher in nativeLibraryDir (W^X allows it there), imports them into a windowless Vulkan device and renders its window pass into them (android_hosted.rs). Each app library links the engine statically, so the engine-dylib identity handling of wm-dyn is not needed. Children have no JVM: assets are read from the APK file, audio device lookup no longer goes through Java, and the startup/resize extra draw of the Activity build is repeated so the first frame carries its text. On a phone the WM asks for the soft keyboard only while the child reports a focused text field. Proven on a Pixel 11 Pro XL: all twelve phone apps launch as processes (first frame 1.6-2.4 s cold), taps reach them. Not yet: HTTP in children (the Activity build borrows Java's), clipboard/permission/file-picker relays, idle-app reclaim, and on-device builds of app libraries 2026-09-23 22:34:44 +02:00
black-orange widgets, storybook: the widget catalogue app, some eighty new widgets, a theme store with mixable style sheets, and the rule that a press belongs to whatever took it 2026-09-18 22:56:31 +02:00
ios platform: retained draw lists, shared publications and GPU residency (DL-0..DL-5) 2026-09-15 13:40:23 +02:00
ios-dark platform: retained draw lists, shared publications and GPU residency (DL-0..DL-5) 2026-09-15 13:40:23 +02:00
macos platform: retained draw lists, shared publications and GPU residency (DL-0..DL-5) 2026-09-15 13:40:23 +02:00
macos-dark platform: retained draw lists, shared publications and GPU residency (DL-0..DL-5) 2026-09-15 13:40:23 +02:00
nextstep widgets, storybook: the widget catalogue app, some eighty new widgets, a theme store with mixable style sheets, and the rule that a press belongs to whatever took it 2026-09-18 22:56:31 +02:00
omarchy platform: retained draw lists, shared publications and GPU residency (DL-0..DL-5) 2026-09-15 13:40:23 +02:00
windows platform: retained draw lists, shared publications and GPU residency (DL-0..DL-5) 2026-09-15 13:40:23 +02:00
windows-2000 widgets, storybook: the widget catalogue app, some eighty new widgets, a theme store with mixable style sheets, and the rule that a press belongs to whatever took it 2026-09-18 22:56:31 +02:00
windows-dark platform: retained draw lists, shared publications and GPU residency (DL-0..DL-5) 2026-09-15 13:40:23 +02:00
build_icons.py
README.md

Application styles

These Splash files define the shared widget styles used by the window manager: omarchy, macos, macos-dark, windows, windows-dark, windows-2000, nextstep, ios, ios-dark, android, and android-dark.

Each style has two phases:

  • theme.splash installs semantic roles, typography, spacing, radii, and bevels before stock widgets are registered.
  • widgets.splash applies component geometry and materials after registration. It can replace a widget's shader as well as its properties. Windows 2000's raised buttons and sunken edit fields are examples.

The loader embeds both files for installed/wasm builds. In a native source checkout it reads widgets/themes/<style>/ on each selection. Edit either file and choose the same style again from the WM's style picker to hotload it. End a generated assignment-only Splash module with true so its last assignment is evaluated as a statement.

The WM keeps its Omarchy top bar. Click the current style name to open the dropdown. Modern desktop and mobile styles also have a Light/Dark button. Its Applications launcher, Windows Start menus, window chrome, and hosted apps use the selected appearance.

desktop_style::StyleSheet carries both phases to existing process clients through StudioToApp::Custom. Window receives the message and requests an application Splash reload with Apply::ScriptReapply. Module clients re-evaluate their registrations in their existing isolates with the same apply mode. Widget identities, editable text, and application Rust state are retained. Initialize persistent script models only when !vm.is_reload(); read the existing mod.state from application Splash. See examples/counter/src/main.rs. Dynamic View.on_render children and embedded Splash isolates reapply the style too. Embedded Splash widgets inherit the stylesheet and reapply their existing widget tree in their own isolate.

Applications should inherit the stock component styles and read theme.* for custom drawing. Apps using the older WM palette adapter can read makepad_wm_theme::current_for_vm during registration, or from their owning VM through Cx::with_vm. Avoid process-wide immutable palette caches: appearances can change while an app is open. Explicit app overrides still take precedence.

The framebuffer crossfade lives in apps/wm/src/scene.rs. It freezes the old GPU render target while the live scene renders the new style; it does not take screenshots, rebuild app instances, or put transitions in the widget system. Shell geometry interpolates over the same 650 ms interval. Floating desktop rectangles are stored separately from the Omarchy tiling tree, so switching back restores the tiling arrangement.

The macOS dock overlays the desktop; dragging keeps the title bar reachable but allows window bodies behind the dock or partly offscreen. Terminals render only their background with opacity (MAKEPAD_WM_TERM_OPACITY, default 0.78 0.70 for focused/unfocused); text and ANSI cell colors remain crisp. Their foreground and background follow the active light/dark stylesheet without restarting the PTY. color_terminal_bg and color_terminal_text are separate semantic roles: Windows 2000 and Android use opaque black consoles, while NeXTSTEP uses white. The palette adapter exports them as term.background and term.foreground. Declare both in each style so a reload resets the previous console palette. The terminal opts into Window.body.keyboard_resize: true; this KeyboardView mode reflows content above the animated keyboard instead of panning the whole terminal out of view. Its grid and PTY resize with the available space.

widgets/src/backdrop.rs supplies ordered compositor checkpoints. Windows are composited from back to front, and a glass surface samples a checkpoint below it. Disjoint sampling footprints share a Gaussian stack, including the kernel's support outside the visible surface. Intervening opaque or translucent content that overlaps the footprint starts a new checkpoint. The dock is the final consumer. Requested blur levels are combined before drawing the pyramid, so unused deeper passes are skipped. Explicit producer/consumer links preserve GPU ordering when pass IDs are recycled. MAKEPAD_WM_TRACE_BLUR=1 logs stack and pass counts when they change; normal operation does not log each frame.

In a checkout, build with cargo build --release -p makepad-wm, then launch ./target/release/wm --remote from the checkout root. Applications launch on demand with cargo run --release -p <package>; there is no binary collection to prepare. The app's window shows Cargo's compiling or build-wait stage before the process connects, then fades into its first frame. Installed distributions without a source checkout use sibling executables.

NeXTSTEP uses black focused title bars, gray beveled window controls, square widgets, a right-hand vertical application dock, and its own icon family. Its launcher opens a draggable Workspace palette with attached submenu columns. Hold the secondary mouse button on the desktop or a window title bar, drag through the menu and release to choose a command. The popup follows the pointer and opens submenus to the left near the screen edge. The Omarchy top bar and shared application state remain in place while switching styles.

Application icons use AppIcon{name: "files" width: 32 height: 32}. The default style: "auto" follows the application's Splash stylesheet; standalone apps use the host OS family. An explicit style ID is available for galleries. color retints the Omarchy artwork; opacity preserves the other families' own colors. Window captions derive their icon name from window.app_id (or the binary name), and the WM's dock/taskbar/launcher use the same AppIconDraw renderer.

Each family has editable icons/<app-id>.svg assets. macOS dark and light share app artwork, as on the OS. Unknown IDs use that family's app.svg. Add or edit an SVG and reselect the style to hotload it; the complete icon sources travel in the stylesheet to existing process and module apps. Unchanged sources keep their parsed geometry cache. python3 widgets/themes/build_icons.py rebuilds the bundled artwork families using only Python's standard library.

Use original application symbols within each OS's visual style. Files uses a folder with documents, and Browser uses a web window with a globe; do not use the Finder face or Safari compass artwork.

Application surfaces should use the shared theme roles (or app-specific aliases that resolve to those roles), including corner_radius and container_corner_radius. Keep content colors such as chart series and model axes separate. Filled accent actions use color_text_on_accent.

Mark live fields that contain runtime UI state with #[apply_state] alongside #[live]: stylesheet ScriptReapply preserves these values, while explicit Eval edits and ordinary source reloads still apply. Standard panel visibility, checkbox state, and dropdown selection use this path.

On macOS, the WM captures the complete window into a GPU texture and warps that surface into its application icon in the dock. Minimize and restore share the same reversible progress, without resizing or relaying out the application during the animation. A style change invalidates minimized snapshots so the restored window uses the current theme. MAKEPAD_WM_TRACE_WARP=1 enables the capture diagnostics using ordinary logs. For frame inspection, MAKEPAD_WM_WARP_SECONDS=5 slows the default 0.62-second animation.