This has been introduced way back in
be297d9d14 but is never used anywhere.
If compositors want to save the old dimensions before reacting to a
fullscreen or maximize event they can just grab the sizes within their
event handlers instead.
For XWayland surfaces that start maximized, it's best to send an initial
Configure event to set the size of the surface before mapping it. This
reduces visual glitches since the application sees the correct maximized
size when performing its initial layout and drawing.
wlroots surfaces emit their first "map" event after the XWayland window
has already been mapped and the first frame has been drawn & committed.
This is too late to send the initial Configure event.
So, add a new "map_request" event which is emitted immediately before
telling XWayland to map the window. Compositors can connect to this
event to send the initial Configure event to an XWayland app based on
its requested maximized (or fullscreen) state.
Compositors should not place anything visually on the screen at this
point but rather wait until the "map" event as before.
This function allows compositors to set the _NET_WORKAREA property on
the root window. XWayland clients use _NET_WORKAREA to determine how
much of the screen is not covered by panels/docks. The property is used
for example by Qt to determine areas of the screen that popup menus
should not overlap (see QScreen::availableVirtualGeometry).
Translating the right/bottom coordinates from offsets to absolute
coordinates in wlroots (rather than in the compositor) was supposed to
be more reliable, since wlroots had access to the X11 screen size.
It ended up being less reliable, because the screen size values
(xwm->screen->width_in_pixels/height_in_pixels) are not updated when the
output layout changes.
So let's remove the translation from wlroots, and let the compositor
figure it out. From what I can understand of the current XWayland code,
the X11 screen size should generally match the overall wlr_output_layout
bounding box, which the compositor has access to.
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.
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()
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.
32daa43a45 has removed the asymmetry in
the relationship of a wlr_surface and an unmapped wlr_xwayland_surface,
when wlr_surface.role_data wasn't NULL but wlr_xwayland_surface.surface
was. However, this also means that
wlr_xwayland_surface_from_wlr_surface() now returns NULL if the
wlr_surface is unmapped. Fix the documentation to reflect this.
Isaac Freund
Consolatis
Simon Ser
Vaxry
John Lindgren
JiDe Zhang
Kirill Primak
novenary