diff options
| author | srdusr <[email protected]> | 2025-05-30 01:12:00 +0200 |
|---|---|---|
| committer | srdusr <[email protected]> | 2025-05-30 01:12:00 +0200 |
| commit | 3f2ac4d85c4e66c2f1ae6622bf3c2f302abe93b9 (patch) | |
| tree | ba933aa00823a47a34715a09d15ffbf30a25b923 /docs | |
| parent | 49ded5541243408e50a391f95bdca037c370a709 (diff) | |
| download | srdwm-3f2ac4d85c4e66c2f1ae6622bf3c2f302abe93b9.tar.gz srdwm-3f2ac4d85c4e66c2f1ae6622bf3c2f302abe93b9.zip | |
Detect XWayland dialogs via WM_TRANSIENT_FOR, not just native xdg_toplevel parent
Window::is_dialog (close-button-only titlebar, no traffic lights) was
only ever set from a native xdg_toplevel's own parent() - redraw_
decoration_buffer's is_dialog computation called dw.toplevel(), which
is always None for an XWayland-backed DWindow (X11Surface's own
accessor is x11_surface(), a different method), so the .unwrap_or(false)
fallback made every XWayland dialog - a GTK "Save As", an app's own
"About" box, anything setting the ICCCM transient-for hint - always
draw with the full three-button titlebar and traffic-light colours,
even though the feature this was built for explicitly wanted the
opposite. Documented as a known gap at the time; now closed.
redraw_decoration_buffer now also checks X11Surface::is_transient_for()
for an XWayland window. property_notify gained a WmWindowProperty::
TransientFor arm that re-runs redraw_decoration_buffer, for a client
that sets the hint slightly after its own initial map - the same
"read fresh every call" pattern the existing xdg_toplevel::parent()
check already relied on, extended to catch a late X11 property the way
the Wayland equivalent (set_parent, any time) already was.
Diffstat (limited to 'docs')
0 files changed, 0 insertions, 0 deletions