Every Kael window is created throughDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/Augani/kael/llms.txt
Use this file to discover all available pages before exploring further.
App::open_window, which accepts a WindowOptions struct and returns a typed WindowHandle<V>. Once open, you interact with the window through its handle or through the &mut Window reference passed to your root view’s callbacks. This page documents the configuration types, handle APIs, focus primitives, and event dispatch phases that govern window behavior.
WindowOptions
WindowOptions is the primary configuration struct for new windows. All fields have sensible defaults via WindowOptions::default().
Initial state and restore size of the window.
None inherits the platform default. See WindowBounds for the available variants.Titlebar configuration. Set
appears_transparent: true to hide the default system titlebar and draw a custom one. Set to None to suppress the titlebar entirely.Whether the window should be focused (brought to the foreground) immediately after creation.
Whether the window is initially visible. Set to
false to create a hidden window and show it later.The type of window to create. Options:
Normal, PopUp (always on top), Floating (on top of its parent), Overlay (above fullscreen apps).Whether the user can drag the window.
Whether the user can resize the window.
Whether the window can be minimized.
The display to open the window on.
None uses the main display.The background painting mode for transparent window areas. See
WindowBackgroundAppearance.Application identifier used by desktop environments (e.g. on Linux) to group windows belonging to the same app.
Minimum dimensions the user can resize the window to.
Whether to use server-side or client-side decorations. Wayland only. See
WindowDecorations.macOS 10.12+ native window tab group name. Windows sharing the same identifier are grouped as tabs.
When
true, mouse events pass through to the windows behind this one. Useful for transparent overlay windows.Parent window handle for creating child windows. The child window will be owned by the parent at the platform level.
WindowBounds
WindowBounds controls the initial visual state of the window. Each variant carries a Bounds<Pixels> that represents the window’s restore size — the size it returns to when un-maximized or un-fullscreened.
WindowBounds::Windowed(bounds)
WindowBounds::Windowed(bounds)
Opens the window in a normal windowed state at the given position and size.
WindowBounds::Maximized(bounds)
WindowBounds::Maximized(bounds)
Opens the window maximized.
bounds is the restore size used when the window is un-maximized.WindowBounds::Fullscreen(bounds)
WindowBounds::Fullscreen(bounds)
Opens the window in fullscreen mode.
bounds is the restore size.Helper: WindowBounds::centered
WindowBounds::Windowed that positions the window at the center of the primary display.
WindowHandle<V>
WindowHandle<V> is a typed, copyable handle to an open window whose root view is V. It does not keep the window alive on its own — the window stays open as long as it is displayed on screen.
WindowHandle<V> derefs to AnyWindowHandle, so any method available on AnyWindowHandle is also available directly.Key methods
Err (or None) if the window has been closed.
AnyWindowHandle
AnyWindowHandle is a type-erased, copyable handle to any open window. Use it when you need to store or pass a window reference without knowing its root view type at compile time.
Key methods
Appearance enums
WindowAppearance
Controls the visual theme mode reported to the operating system. On macOS this maps to NSAppearance names.
Light. Vibrant variants use the macOS vibrancy material effect, which blends the window content with the desktop behind it.
WindowBackgroundAppearance
Determines how Kael paints the window background in areas with no opaque content.
WindowDecorations
Specifies whether the window manager (server) or your application (client) draws window chrome such as title bars and resize handles. Applies only on Wayland.
WindowControls
A struct that describes which control operations the current platform supports. Returned by the platform on window creation and inspected to decide whether to render custom control buttons.
true (Kael assumes the platform can do everything, unless told otherwise).
Focus management
Kael’s focus system is built aroundFocusHandle, a reference-counted token that identifies a focusable element in the rendered frame.
FocusHandle
Moves keyboard focus to the element associated with this handle.
Returns
true if this handle’s element currently holds focus.Returns
true if this handle’s element, or any of its descendants, is focused.Returns
true if this handle is focused or is a descendant of the focused element.Returns
true if other is a descendant of this handle in the last rendered frame.Dispatches an action as if it originated from this focus handle’s element.
Returns a
WeakFocusHandle that does not prevent the focus slot from being released.Builder method that sets the element’s position in the tab order.
Builder method that controls whether tab navigation will land on this element.
Focusable trait
Any view that can receive keyboard focus should implement Focusable:
VisualContext::focus method calls focus_handle() internally.
DispatchPhase
Events in Kael propagate through the element tree in two phases: capture then bubble.
Bubble (default)
Bubble (default)
Mouse events are dispatched front-to-back (foreground elements first). Keyboard events travel from the focused element up to the root. This is the phase you should use for almost all event handlers.
Capture
Capture
Mouse events are dispatched back-to-front (background elements first). Keyboard events travel from the root down toward the focused element. Use this for special cases like clearing “pressed” state. Stopping propagation during capture affects all handlers that rely on detecting non-local events in this phase.