We'll soon introduce a unified wlr_surface map event. Up until now, compositors
have been using wlr_xwayland_surface's map event to setup various wlr_surface
related listeners (e.g. commit). This will no longer be possible when that
event is moved over to wlr_surface. Introduce new events where the compositor
can add/remove wlr_surface event listeners.
X11 clients expect a ConfigureNotify after a ConfigureRequest. If
the compositor/window manager chooses not to honor the request
(e.g. due to the window being maximized), XWayland will not send a
"real" ConfigureNotify event and the window manager is expected to
send a synthetic event instead. Otherwise, the X11 client is left
waiting and may not repaint its window properly.
For comparison, see Openbox's client_configure() or Weston's
weston_wm_window_send_configure_notify().
v2: Move logic to wlr_xwayland_surface_configure()
This is needed for compositors that want to reserve space for
XWayland panels. Such a feature can be useful in a "transitional"
setup, where only the X11 window manager and compositor is replaced
but other components of an X11 desktop environment are still used.
This change simply reads the X11 property; the compositor is free
to ignore it. Thus, compositors that don't want to support such a
"transitional" feature are not impacted.
v2: Update xwayland_surface_associate()
If a window is unmapped too quickly, we might receive UnmapNotify before
we get the corresponding wl_surface, which will later lead to
associating the same window twice. To fix this, move the NULL surface
check to xwayland_surface_dissociate(), which makes resetting the
unpaired link and the wl_surface object ID unconditional.
Fixes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3552
The dep allows us to check dep variables to discover supported
features. With the binary we assume none of the features are
supported. If a user forgets to install the pkg-config file (e.g.
because it's in a split package) we end up incorrectly disabling
all features. Instead let's error out.
Rename xwm_map_shell_surface() to xwayland_surface_associate().
This function doesn't actually "map" the surface in Wayland
parlance, the wl_surface may not have a buffer attached yet.
This can be used to know when wlr_xwayland_server decides to start
a new Xwayland process. At that point the wl_client has already
been created but the Xwayland process hasn't been started yet.
Always keep it initialized, so that we don't have to check for
xsurface->surface_id.
Will help with WL_SURFACE_SERIAL support, which adds a new way for
a surface to be unpaired.
This allows whatever the user calls from the signal handlers to react to observe
the new state rather than the old, e.g. that a surface is no longer mapped in
the unmap handler.
The original commit introduced a bug by transposing the order of
some of the fields in xcb_size_hints_t. Since XCB ICCCM support is
required now, we can just eliminate the duplicate structs.
With minor changes:
- Remove #ifdef HAS_XCB_ICCCM guards
- Fix #includes
- Fix references to local size_hints struct
This reverts commit 12b9b1a4bd.
Using Xwayland -displayfd means we don't need to worry about handling
SIGUSR1 to second guess when Xwayland is ready and write to the pipe:
just let it do that write when it would be sending SIGUSR1 otherwise.
Closes: #3356
A launchee notifies with a "remove"¹ message when done starting up.
Catch these and forward to the compositor. This allows the compositor to
end the startup sequence that might have been started by another
protocol like xdg-activation.
We don't handle other messages since we expect the launcher to use a
wayland protocol like xdg-activation.
While `_NET_STARTUP_ID` helps to associate toplevels with startup-ids
this signals the end of the startup sequence.
1) https://specifications.freedesktop.org/startup-notification-spec/startup-notification-latest.txt
