We only listen for those so we know there's no more X11 clients that we
should keep the Xwayland server alive for. Check first that we really did
request Xwayland to be handled on demand for this, otherwise the check is
superfluous, even harmful.
https://gitlab.gnome.org/GNOME/mutter/issues/719
The Xwayland manager now has 4 distinct phases:
- Init and shutdown (Happening together with the compositor itself)
- Start and stop
In these last 2 phases, handle orderly initialization and shutdown
of Xwayland. On initialization We will simply find out what is a
proper display name, and set up the envvar and socket so that clients
think there is a X server.
Whenever we detect data on this socket, we enter the start phase
that will launch Xwayland, and plunge the socket directly to it.
In this phase we now also set up the MetaX11Display.
The stop phase is pretty much the opposite, we will shutdown the
MetaX11Display and all related data, terminate the Xwayland
process, and restore the listening sockets. This phase happens
on a timeout whenever the last known X11 MetaWindow is gone. If no
new X clients come back in this timeout, the X server will be
eventually terminated.
The shutdown phase happens on compositor shutdown and is completely
uninteresting. Some bits there moved into the stop phase as might
happen over and over.
This is all controlled by META_DISPLAY_POLICY_ON_DEMAND and
the "autostart-xwayland" experimental setting.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
When rushing to unmanage X11 windows after the X11 connection is closed/ing,
this would succeed at creating a stack operation for no longer known windows.
Simply avoid to queue a stack operation if we know it's meaningless.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
Unmanaging the windows may trigger stack operations that we later try
to synchronize despite being in dispose() stage. This may trigger
MetaStackTracker warnings when trying to apply those operations.
Switching destruction order (First dispose the X11 stack representation,
then unmanage windows) won't trigger further stack changes on X11 windows
after having signaled MetaDisplay::x11-display-closing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
What "restart" means is somewhat different between x11 and wayland
sessions. A X11 compositor may restart itself, thus having to manage
again all the client windows that were running. A wayland compositor
cannot restart itself, but might restart X11, in which case there's
possibly a number of wayland clients, plus some x11 app that is
being started.
For the latter case, the assert will break, so just make it
conditional. Also rename the function so it's more clear that it
only affects X11 windows.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
In the case mutter is a x11 compositor, it doesn't matter much
since the stack tracker will go away soon. In the case this is a
wayland compositor with mandatory Xwayland, it matters even less
since the session would be shutting down in those paths.
But if this a wayland compositor that can start Xwayland on demand,
this is even harmful, as the MetaStackTracker should be cleared of
x11 windows at this moment, and we actually did right before dispose
on ::x11-display-closing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
If the display is closed prematurely, go through all windows that
look X11-y and remove them for future calculations. This is not
strictly needed as Xwayland should shut down orderly (thus no client
windows be there), but doesn't hurt to prepare in advance for the
cases where it might not be the case.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
We don't strictly need it for wayland compositors, yet there are
paths where we try to trigger those passive grabs there. Just
skip those on the high level code (where "is it x11" decisions
are taken) like we do with passive button grabs.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
Commit 09bab98b1e tried to avoid several workspace changes while in
window construction, but it missed a case:
If we have a window on a secondary monitor with no workspaces enabled
(so it implicitly gets on_all_workspaces = TRUE without requesting it)
and trigger the creation of a second window that has the first as
transient-for, it would first try to set the first workspace than the
transient-for window and then fallback to all/current workspace.
After that commit we only try to set the same workspace than the
transient-for window, but it gets none as neither is on a single workspace,
nor did really request to be on all workspaces.
Fixes crashes when opening transient X11 dialogs in the secondary monitor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/714
Similar to gtk commit f507a790, this ensures that the valist variant of
the marshaller is used. From that commit's message:
```
If we set c_marshaller manually, then g_signal_newv() will not setup a
va_marshaller for us. However, if we provide c_marshaller as NULL, it will
setup both the c_marshaller (to g_cclosure_marshal_VOID__VOID) and
va_marshaller (to g_cclosure_marshal_VOID__VOIDv) for us.
```
https://gitlab.gnome.org/GNOME/mutter/merge_requests/697
By putting `NULL` as the C marshaller in `g_signal_new`, you
automatically get `g_cclosure_marshaller_generic`, which will try to
process its arguments and return value with the help of libffi and
GValue.
Using `glib-genmarshal` and valist_marshallers, we can prevent this so
that we need less instructions for each signal emission.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/697
Double negations are the spawn of the devil, and is_non_opaque() is
used like that to find out if it's opaque most often, change the
function name to see the glass half full.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/698
The MetaBackgroundActor was ignoring the unobscured area altogether,
and just painted according to the clip area. Check the unobscured
area too, as it might well be covered by client windows.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/698
Wayland clients do this through the opaque region in the surface
actor. However X11 clients were considered fully transparent for
culling purposes, which may result in mutter painting other bits
of the background or other windows that will be painted over in
reality.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/698
We want to clip it away if 1) The window is fully opaque or
2) If it's translucent but has a frame (as explained in the comment
above). The code didn't quite match and we were only applying it on
case #2.
Case #1 is far more common, and saves us from pushing some drawing
that we know will be covered in the end.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/698
`g_object_notify()` actually takes a global lock to look up the property
by its name, which means there is a performance hit (albeit tiny) every
time this function is called. For this reason, always try to use
`g_object_notify_by_pspec()` instead.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/703
We first set the workspace to the transient-for parent's, and then
try to set on the current workspace. If both happen, we double the
work on adding/removing it from the workspace, and everything that
happens in result.
Should reduce some activity while typing on the Epiphany address
bar, as the animation results in a number of xdg_popup being created
and destroyed to handle the animation.
https://gitlab.gnome.org/GNOME/mutter/issues/556
Since the API version was added, we've bumped it at some point late-ish in
the cycle when enough changes had accumulated (but way after the first ABI
break). Automate that process by computing the API version automatically
from the project version:
With this commit, the new API version will be 5 for the remaining 3.33.x
releases and all 3.34.x stable versions; 3.35.1 will then bump it to 6 and
so forth.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/696
Since commit 0eab73dc, actors are only allocated when they are actually
visible. While this generally works well, it breaks - because of *course*
it does - ClutterClones when the clone source (or any of its ancestors)
is hidden.
Force an allocation in that case to allow the clone's paint to work as
intended.
https://gitlab.gnome.org/GNOME/mutter/issues/683
The default configuration of libinput-gestures utility invokes wmctrl to
switch between desktops. It uses wmctrl because this works on both Xorg
and Wayland (via XWayland). Unfortunately, this generates the following
warning message every time, in both Xorg and Wayland desktops:
"Received a NET_CURRENT_DESKTOP message from a broken (outdated) client
who sent a 0 timestamp"
The desktop switch still works fine. The tiny code change here removes
this specific warning because, as the prefacing code comment originally
said and still says, older clients can validly pass a 0 time value so
why complain about that?
I also refactored the "if (workspace)" code slightly to avoid the double
test of the workspace value.
This is submitted for MR
https://gitlab.gnome.org/GNOME/mutter/merge_requests/671.
On X11, mutter needs to keep a grab on the locate-pointer key to be able
to trigger the functionality time the corresponding key combo is
pressed.
However, doing so may have side effects on other X11 clients that would
want to have a grab on the same key.
Make sure we only actually grab the key combo for "locate-pointer" only
when the feature is actually enabled, so that having the locate pointer
feature turned off (the default) would not cause side effects on other
X11 clients that might want to use the same key for their own use.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/647
