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.
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
As more options are added, more fields will be duplicated. Let's
just embed the struct in wlr_xwayland_server so that we don't need
to keep both in sync.
This property is present on all modern X11 instances. The nonpresence of
it requires applications to fall back to XQueryTree-based logic to
determine stacking logic (e.g., to determine what surface should get
Xdnd events).
These code paths are effectively untested nowadays, so this makes it
more likely for wlroots to "break" applications. For instance, the
XQueryTree fallback path has been broken in Chromium for the last 10
years.
It's easy enough to maintain this property, so let's just do it.
Fixes#2889.
In certain situations windows can have their input field set to false
but still expect to receive input focus by passively listening to key
presses via a parent window. The ICCCM specification outlines how focus
should be given to clients.
Further reading: https://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7
Relates to #2604
Without this information, compositors have no way to tell whether
or not to consider the position information valid. Most notably,
a compositor needs to know if it should pick a position for the
surface or use the position sent in the configure request.
This is a common interface that can be used for all primary selection
protocols, as discussed in [1]. A new function wlr_seat_set_primary_selection
is added to set the primary selection for all protocols.
The seat now owns again the source, and resets the selection to NULL when
destroyed.
[1]: https://github.com/swaywm/wlroots/issues/1367#issuecomment-442403454
This commits completely refactors wlr_gtk_primary_selection. The goal is to
remove gtk-primary-selection state from the seat and better handle inert
resources where it makes sense.
wlr_seat_client.primary_selection_devices has been removed and replaced by
wlr_gtk_primary_selection_device. This allows us to make offers inert when the
current selection is replaced.
wlr_seat_set_primary_selection has been removed because it relied on wlr_seat
instead of wlr_gtk_primary_selection_device_manager. A new function,
wlr_gtk_primary_selection_device_manager_set_selection (candidate for the
longest function name in wlroots) has been added. It doesn't take a serial
anymore as serial checking only makes sense for set_selection requests coming
from Wayland clients (serial checking is now done in the Wayland interface
implementation).
Since wlr_gtk_primary_selection_device_manager is now required to set the
selection, a new function wlr_xwayland_set_gtk_primary_selection_device_manager
(candidate number two for longest function name) has been added.
Devices are now made inert when the seat goes away.
Future work includes removing the last primary selection bits from the seat,
mainly wlr_seat.primary_selection_source and wlr_seat.events.primary_selection,
replacing those with new fields in wlr_gtk_primary_selection_device. Or maybe
we could keep those in the seat and replace them with a re-usable interface
(for future zwp_primary_selection_v1 support). We need to think how we'll sync
these three protocols (GTK, X11 and wayland-protocols).
See https://github.com/swaywm/wlroots/issues/1388
This introduces -DWLR_USE_UNSTABLE and adds information regarding the
stability status to all headers. I started with a conservative set of
headers to mark as stable:
- types/wlr_matrix.h
- util/edges.h
- util/log.h
- util/region.h
- xcursor.h
153f37bdf5 (#1145) removed the
wlr_xwayland_is_unamanged function while fixing OR, because it was
belieived that it's supposed to work around the broken OR handling.
This was a misunderstanding. is_unmanaged is (while sort of a hack)
intended to work around inherent differences between "real" X sessions
and our Xwayland/wayland situation.
The main reason it exists is to support applications like rofi and dzen,
while not handing focus to other OR windows (which should *not* be
required).
Traditionally, these applications just grabbed input from X and didn't
need to be focused by any logic in the WM. Which of course doesn't work
in wayland compositors. So we have to give them focus in some way.
Giving *every* OR window focus, breaks other applications that don't
expect focus to change.
A testcase that was pointed out to me where wlr_xwayland_is_unamanged was
breaking things is https://github.com/swaywm/sway/issues/2128 (syncplay,
gitk, gitgui)
Supposedly it broke using keyboard to navigate the menus.
I can't reproduce this with this patch. The popups can be navigated as
long as the parent has focus.
The override_redirect flag can change on configure notify and
on map notify. This adds an event to know when it changes.
This removes wlr_xwayland_surface_is_unmanaged which was wrongly
using the window type to decide whether the view should be
unmanaged.
A similar patch was proposed to Weston, but has never been
merged upstream [1].
[1]: https://patchwork.freedesktop.org/patch/211161/
Makes the xwayland startup process two phased.
The first phase just initialises the X11 sockets.
The second phase starts the Xwayland server itself.
When starting xwayland lazily the second phase will be postponed until
a client has connected to the X11 socket.
Changes in behaviour:
The DISPLAY environment is now set immediately after the X11 sockets
are created.
When the Xwayland server is killed or crashes, the sockets will not be
recreated, but reused.
Fixes#849: Start up Xwayland lazily
xwm.h was meant to be private, so move it to include/xwayland/xwm.h
We had an ifdef WLR_HAS_XCB_ICCCM in xwayland.h which was easy to move
to xwm, it is not safe to use the WLR_HAS_* in the public headers.
I checked a few of our current users and none rely on xwm.h being
public as expected (rootston, sway, hsroots)
This adds `wlr_xwayland_surface_is_unamanged`, to allow compositors more
fine grained control over XWayland focus.
A surface that is unmanaged should not receive focus, while other
windows that are just override redirect may want it (dmenu).
The way unamanged is determined is taken from wlc.
This is more robust than trying to recopy a few fields.
Note: wlr_xwayland->events.ready now resets after each trigger, so one can
hook on it again and be called when restart is ready
