pub enum DisplayMode {
Windowed,
Borderless {
monitor: Option<MonitorId>,
},
}Expand description
How a window is presented.
Two variants, deliberately. See the module docs.
Variants§
Windowed
A decorated window the user can move and resize.
Render resolution is the client area, 1:1; a resize recreates the
swapchain. Whether the decorations are drawn by the window system or by
the engine’s UI depends on
ShellCaps::SERVER_DECORATIONS.
Borderless
A frameless window covering a monitor, with the desktop’s video mode untouched.
Fields
monitor: Option<MonitorId>Which monitor to cover, or None for “wherever the window already
is”.
None is not a lazy default — it is the only thing a Wayland
backend can honour, since a client cannot position its own surface
and can only ask xdg_toplevel.set_fullscreen with an output hint
the compositor may ignore. A caller that genuinely needs a specific
monitor checks
ShellCaps::WINDOW_POSITION
first.
Implementations§
Source§impl DisplayMode
impl DisplayMode
Sourcepub const fn is_borderless(self) -> bool
pub const fn is_borderless(self) -> bool
Whether this is DisplayMode::Borderless.
Sourcepub const fn satisfied_by(self, effective: Self) -> bool
pub const fn satisfied_by(self, effective: Self) -> bool
Whether effective is an acceptable answer to self as a request.
Not equality, because Borderless::monitor is not
symmetric: None in a request means “wherever the window already is”,
so any monitor answers it. None in an answer means the backend
cannot say which monitor — which answers a request that did not care,
and does not answer one that named a monitor, because nothing has
confirmed the window is on it.
Comparing the two with == made every granted fullscreen on a backend
that can name the monitor read as refused: X11 fills in
effective_monitor from the window’s origin, so a request for
Borderless { monitor: None } was answered Borderless { monitor: Some(..) } and a UI toggle would have shown “off” over a fullscreen
window.