Module window_system 

Which windowing system a Linux/BSD session is running on, and what that implies for window chrome and modal windows.

Two detectors live here and they are not interchangeable:

• active_window_system predicts, from the environment, which backend winit will pick. It is only valid before a window exists — its one job is deciding WindowAttributes::with_decorations(..), which has to be chosen at window-construction time. It mirrors winit’s own precedence exactly; any divergence means Teksilo and winit disagree about the session and the chrome comes out wrong.
• window_system_for_display_handle reads the live handle of an already-created window. It is authoritative and should be preferred everywhere a window (or a ParentHandle) is in reach — the title-bar host factory and the external-DnD backend both dispatch on it, so they can never disagree with each other or with winit.

Enums

WindowSystem

The windowing system backing a window (or the session, when predicted).

Functions

active_window_system

The window system winit is expected to use for windows created in this process. See the module docs: this is a prediction for the pre-window- creation decisions only. Once a window exists, prefer window_system_for_display_handle.

attach_child_window

Attach child as a child window of parent using NSWindowOrderingMode::Above on macOS. Call this after both windows’ AccessKit adapters have been created (and thus after the child becomes visible). Works for modal and non-modal parented windows alike — popover-as-window, inspector palettes, floating tool panels are all expected to route through this path as the multi-window system matures.

supports_native_modal_windows

Whether a modal dialog should be presented as a real OS window rather than an in-tree overlay.

window_system_for_display_handle

The window system a live window actually runs on, read from its raw display handle. Authoritative — unlike active_window_system it cannot disagree with winit, because the handle is winit’s answer.