Wayland support is not really a "backend" thing, it just lacked a better
place to store its instance pointer. Eventually we'll have a better
place, but prepare for that by initializing it together with the more
similar subsystems.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1833>
The rest of debug flag details are in util.c and util.h, make things
less scattered by moving the rest to util.c too.
While at it, put the coredump:ability setting needed for being suid
there too, so we have a common place for initializing "debug utils".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1833>
MetaDisplay does a lot of things, and is a central part to anything
window management. To let Wayland units have an easier time tearing
down, make it so that the Wayland infrastructure is terminated before
MetaDisplay.
This also makes sure that X11 support is turned off, so that we don't
stumble upon Xwayland terminating due to the Wayland socket connection
being broken. Will mitigate that in a better way in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
In case the shell ignores or can't accept the restart request we should
hide the message that has been just requested to be shown.
As per ::show-restart-message signal documentation, this has to be done by
emitting the signal with a NULL message.
So follow the API properly in such case
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1780>
In non-systemd managed session we are unable to start services on
demand. Instead, gnome-session will start everything at login time,
including any X11 related service (i.e. gsd-xsettings).
However, in order to start gsd-xsettings, Xwayland needs to be started
already. Otherwise it will connect to GNOME_SETUP_DISPLAY and login will
hang at that point.
Fix this by detecting whether mutter is running in a systemd unit. If it
is, we assume that we are systemd managed and the machinery to start the
services works fine. If not, we assume that the session management may
unconditionally try to start X11 related services and Xwayland must be
started in order to not block this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1771>
Make it possible to create persintent virtual monitors using command
line argument. This will not be the only way to create virtual monitors,
the primary way will be using the screen cast API, but using command
line argumenst is convenient for debugging purposes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
It's useful to be able to have very very tiny monitors (e.g. 60x60
pixels) when doing reference testing, as tests have reference images
that the output is compared to. Smaller reference images the less
storage they use.
To avoid annoying pointless warnings when this is done, change the
pedantic workspace work area code to be more forgiving if the work area
happens to match the display size.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
This makes it possible to pass custom properties to backends when
constructing tests. This will be used to create "headless" native
backend instances for testing the headless native backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Make it possible to pass --headless as a command line argument in order
to turn the native backend "headless". This currently doesn't do
anything, but the intention is that it should not use logind nor KMS,
and work completely headless with only virtual outputs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Handle the case of a TOUCH_BEGIN event during window dragging separately
instead of treating it like a TOUCH_UPDATE event: Simply return TRUE to
make Clutter stop event propagation if it's the pointer emulating
sequence and let Clutter propagate the event if it isn't.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/427>
Window dragging should be cancelled when the touch sequences we're using
are no longer available. Also listen to TOUCH_CANCEL events if the
window is grabbed and cancel the grab op when a TOUCH_CANCEL event
happens.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/427>
Make sure to reset all the state that was set for an interactive grab op
back to the defaults after a grab op has ended.
Especially important here is setting grab_frame_action back to FALSE,
since this will constrain window-titlebars to the panel. We set this to
TRUE on some grabs, for example when resizing, but not when moving
windows. Since this remained being set to TRUE, it would also constrain
non-grab window movements, like calling MetaWindow.move_frame(), which
is used by gnome-shells OSK. By resetting it back to FALSE after a grab,
the OSK can now always move non-maximized windows to the position it
wants.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1736>
Commit afa43154 tried to make sure the focus was properly changed when
calling focus_default_window() by checking the focused window just after
trying to set the focus.
However, the X11 “Inter-Client Communication Conventions Manual” version
2.0 (ICCCM 2 for short) states that some X11 client may want to use a so
called “globally active input” model in which case the client expects
keyboard input and set input focus even when it's not one of its own
window.
To comply with this, when dealing with such clients, mutter will not
change the focus and send a WM_TAKE_FOCUS message instead.
That mechanism will defeat the logic introduced by commit afa43154
because the focused window is not changed in this case. As a result, the
input focus will fallback to the no-focus window.
To avoid this, only check that the focus change occurred for windows
using a synchronous focus model.
v2: Split specific test for "globally active input" model (Florian).
v3: Remove the check for window->unmanaging which is useless (Jonas).
Fixes: afa43154 - "core: Make sure focus_default_window() worked"
Close: https://gitlab.gnome.org/GNOME/mutter/-/issues/1620
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1716>
X11 clients can use different models of input handling, of which some
may not result focus being set synchronously.
For such clients, meta_focus_window() will not change the focus itself
but rely on the client itself to set the input focus on the desired
window.
Add a new MetaWindow API to check when dealing with such a window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1716>
GObject signals pass the emitting GObject as the first argument to
signal handler callbacks. When refactoring the grab-op-begin/end signals
to remove MetaScreen with commit 1d5e37050d,
the "screen" argument was replaced with a "display" argument instead of
being removed completely. This made us call the signal handlers with two
identical MetaDisplay arguments, which is very confusing and actually
wasn't handled in a grab-op-begin handler in gnome-shell.
So fix this by not adding the MetaDisplay as an argument to those
signals, GObject will take care of that for us.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1734>
When a transfer request is done to the MetaSelectionSourceRemote source,
it's translated to a SelectionTransfer signal, which the remote desktop
server is supposed to respond to with SelectionWrite.
A timeout (set to 15 seconds) is added to handle too long timeouts,
which cancels the transfer request.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1552>
Since commit c255031b6d, we allow some modifier+scroll events to
pass through to Clutter to enable gnome-shell to handle them. That
action shouldn't trigger a modifier-only action at the same time, so
reset the corresponding tracking just like we do for modifier+click.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1695>
Since commit c255031b6d we pass scroll-events through to
the compositor if the window_grab_modifiers are pressed;
in order to allow gnome-shell to check for those events,
expose the struct member as a MetaDisplay property.
Also take the opportunity to pick a more generic name, now
that the modifier is no longer used exclusively for mouse
clicks (unless we maintain the notion of scroll events as
button 4 and 5 "clicks").
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1695>
We remove pending pings when unmanaging a window, but currently
don't prevent new pings to be scheduled after that.
The previous commit fixed a code path where this did indeed happen,
but as the result of gnome-shell trying to attach a Clutter actor
to a non-existent window actor is pretty bad, also guard can_ping()
against being called for an unmanaging window.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2467
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1676>
This seems to have been the default in the past, but was (accidentally?) modified
by 8adab0275.
For GNOME 40, we'll be returning to our root with horizontal workspaces, so instead
of overriding it in GNOME Shell side, change the default back to what it once was.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1684>
<super> is considered a system modifier, and applications cannot use it
for keyboard shortcuts or as button modifier. It doesn't seem too much
of a loss taking <super>+scroll-event away as well, so that it becomes
available to gnome-shell/extensions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1674>
find_focusable_ancestor() may pick an ancestor window which is not
mapped or hidden, and setting focus on that window will fail.
Be a tad more selective when looking for a focusable ancestor, to reduce
the chance of meta_window_focus() not focusing the happy chosen one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1643>
The function focus_default_window() optionally takes a MetaWindow
argument denoting a window that should not be focused.
That function calls focus_ancestor_or_top_window() which in turn
calls meta_window_focus() to pass focus to another window.
However meta_window_focus() gives no guarantee that the given window
will end up being the one focused, and can fail in various and creative
ways.
If that fails, we could possibly end up with the focus window being the
one to avoid, while the caller assumes focus was changed, going as far
as asserting that fact like meta_window_unmanage() does.
As a result, mutter may abort simply because meta_window_focus() failed
to set focus on the expected window.
To avoid that issue, check that the focus did not end up on the window
that we explicitly did not want, and if that's the case, simply fallback
to the default focus window.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/862
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1643>
As planned and prepared with the last commits, let ClutterStage take
care of tracking input devices and their respective actors. This means
we now can remove the old infrastructure for this from
ClutterInputDevice.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1633>
Making this an event is overly convoluted, accounting that we
emit the event, then convert it to a ClutterStage signal, then
its only consumer (a11y) sets the active ATK state.
Take the event out of the equation, unify activation/deactivation
of the stage in MetaStage, and use it from the X11 backend too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
