Module window 

Backend-neutral description of the app’s window and its native menu bar.

Every launch path (the CLI, the C-ABI, the SDKs) resolves the same values - size, title, clear color, chrome, menu bar - before a window exists, and a window backend consumes them when it opens one. Keeping the description here means the composition point can build it without naming a backend, and a second window backend can consume it without inventing a parallel type.

The menu tree (MenuModel, Menu, MenuEntry) is pure data: it says what the menu bar contains, not how a platform draws it. lumen-os-menu re-exports these types and owns the native attach.

Structs

Menu

One submenu (<menu label="File">...</menu>).

MenuModel

The app’s native menu bar, as parsed from <menubar>.

WindowGeometry

Snapshot of geometry handed to WindowOptions::on_close_state so the embedder can persist (position, size, maximized) to disk.

WindowOptions

Everything a window backend needs to open the app’s window.

Enums

MenuEntry

One submenu entry - either a clickable item or a separator.

Constants

DEFAULT_CLEAR

Fallback GPU clear color painted before the very first frame - what a user sees for an instant during window creation, and behind any pixel the app’s tree doesn’t cover. This is the single Rust-side source of truth for that fallback; lumen_runtime::run::RunOptions::clear (the value every launch path reaches - CLI, FFI, SDK) defaults to it too, so the two never drift apart the way they used to.