Layout in native apps

Run and build natively

To run a layout as a native window:

salam run app.salam --ui=native
salam build app.salam --ui=native

run launches the app; build produces a native executable. This uses the layout DSL but targets Salam's native UI runtime instead of generating browser HTML/CSS/JS files.

What stays the same

• Tree structure of pages/elements and nesting
• Attributes and style properties (including simpler values like 50% and #hex)
• Components (component/بخش), parameters, conditionals/loops in dynamic layouts, and overall DSL patterns

The goal is to share much of the UI description, while runtime behavior and supported features depend on the target engine.

Differences and limitations vs web

The native target is not a browser, so web-specific features may be unavailable or behave differently. Elements/capabilities tied to the browser DOM/runtime (such as raw browser scripts, iframes, some web-only media/embed features, or HTML document APIs) do not map the same way. The compiler can report errors/warnings for features not supported in native UI targets.

For native interactivity, use patterns and APIs supported by Salam's UI runtime and keep application logic in Salam code as appropriate for the target.

Desktop paths in Salam

• Native DSL (--ui=native): UI rendered by Salam's engine; useful when you want a browserless native UI.
• WebView (gui.webview): a native window hosting HTML/CSS/JS content (Tauri/Electron-like model); useful when you want web tech inside a desktop shell.
• Other graphics libraries: such as gui.raylib for games/rendering-specific use cases.