This adds the actual input capturing rerouting that takes events and
first hands them to the input capture session, would it be active.
Events are right now not actually processed in any way, but will
eventually be passed to a libei client using libeis.
A key binding for allowing cancelling the capture session is added
(defaults to <Super><Shift>Escape) to avoid getting stuck in case the client
doesn't even terminate the session.
The added test case makes sure that the pointer moves again after
pressing the keybinding.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
With window_is_terminal gone, "strict" and "smart" focus mode have no
behavioural difference. Let's broaden the scope of strict focus mode,
such that windows never automatically focus unless they are an ancestor
to the transient.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3063>
As noted in the comments of window_is_terminal, this is a hack. This
code has not been touched for the better part of a decade. App res_class
tends to differ between Wayland and X11, so it is likely that none of
these apps have been recognised as terminals under Wayland ever. Also,
there are reports that strict focus mode also does not work under X11,
likely due to changes in these terminal apps over the years resulting
in different res_class than those manually specified in here. Let's remove
this hack and change strict focus mode accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3063>
Current behavior pushes a window which receives focus to the start of
the MRU list on every workspace it is on. By focusing a sticky window
the default focus on all other workspaces changes as well. This is fine
for sticky windows explicitly marked as sticky by the user but if a
window is on a secondary output and workspaces are only on the primary
output the behavior is unexpected. Instead we want the window to be the
default focus only on the current workspace but also keep those windows
in a relative MRU order to each other on all workspaces.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2681
Fixes: 058981dc1 ("workspace: Focus the default window only if no window is focused")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2909>
This avoids use-after-free when handle_start() is called following
handle_stop() during the lifetime of the MetaProfiler. This happens
on repeated profiling sessions using Sysprof.
Fixes: e16d68372 ("profiler: Add API to register profiler threads")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3076>
We need to juggle with some things here to keep key event ordering
and accounting consistent.
The keyboard internal state changes (and maybe modifier event emission)
happening through meta_wayland_seat_update() should ideally happen
from the same key events that reach the client through wl_keyboard.key,
so that wl_keyboard.modifier events are emitted in the right relative
order to other key events.
In order to fix this, we need to decide at an earlier point whether
the event will get processed through IM (and maybe be reinjected),
thus ignored in wait of IM-postprocessed events.
This means we pay less attention to whether events are first-hand
hardware events for some things and go with the event that does
eventually reach to us (hardware or IM).
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5890
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3044>
Don't try to handle things by threads enabling/disabling the main trace
context on-demand, just have a clear start/stop API. For the D-Bus API,
it becomes more straight forward, and for the persistent variant too, as
it avoids having to pass garbage input when it's known that arguments
will be discarded.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2998>
Persistent profiling was started via an env var, but that's rather hard
to discover and remember without grepping; change to use a command line
argument.
The profiler is started early, even during (though late in)
configuration, but configuration should ideally be instant and pointless
to configure.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2998>
A window may become undecorated while the frame window is
frozen due to updates. In that case we would both miss a
reply for the frame window, and any other means to trigger
the window actor being thawed.
Check the frozen state after destroying the frame, so that
meta_window_x11_are_updates_frozen() may end up changing
opinion if the frame window was caught in this situation.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2639
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2996>
When the X11 display is actually XWayland there's no point to delay the
compositor selection, given that mutter itself is the compositor and
doing this may cause the first X11 client that starts not to receive the
right information (and in some cases misbehave).
Since some toolkits are not handling the compositor selection changes
properly at later times, let's make their life easier by just
initializing the selection as early as the other X11 properties, given
that in this case there's nothing to replace.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2472
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2970>
We are attempting to show windows that do not yet have a
surface/buffer, this makes GNOME Shell avoid transitions
for these windows.
Since on Wayland X11 windows are also Wayland surfaces,
this check is also valid for these, and is thus made more
generic to also cater for these windows.
Eventually, meta_window_update_visibility() is called
when the surface gets its buffer, so the window can be
neatly animated.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2611
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2975>
When selecting the default focus window, is_focusable() was not
considering the new conditions for whether a window should be shown or
hidden that were added to meta_window_should_be_showing() in 39942974.
As a result the default focus window could end up a window already
hidden or hidden once meta_window_flush_calc_showing() is called by
meta_window_focus() when focusing the default window. This would cause
meta_window_focus() to fail, which is an issue if it prevents us from
unfocusing a window when it is getting unmanaged.
Fixes: 399429742 ("x11: Integrate frames client into Mutter")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2644
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2962>
With the frames client, we do no longer handle events for the
frame window inside Mutter. This means we do not get events
"for free" to handle focus on a just clicked frame window.
This results in a background window not ending up focused if
clicked on its frame.
In order to fix this, make the passive button grab extend to
the frame window if a window has one. This brings back
focus-on-click behavior, while treating windows further as
a unitary surface.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2727
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2954>
With the move away from GTK3, and the indirect dependency on GTK4
grown in the GNOME Shell side, we've indirectly gotten a small sneaky
behavioral change: The GTK4 library will, right on dlopen, get
DESKTOP_AUTOSTART_ID for itself and delete it from the environment.
This happens before our own X11 session management code is
initialized, which confuses the hell out of it, into thinking
initialization is actually shutdown, gnome-session does not follow
along with this request, which leaves GNOME Shell into a confused
startup state where it never calls SmcSaveYourselfDone() and grinds
startup to a halt until gnome-session decides to move things forward.
In order to fix this, get the DESKTOP_AUTOSTART_ID before we lend
control to GNOME Shell bits and GTK4 is possibly initialized, and
feed it directly to our X11 session manager bits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2906>
Commit 7e9d9c7eb9 added new API to replace GTK for accelerator
parsing.
Unfortunately there is another case in gnome-shell, where we have
to get the label from the logical binding name rather than the
modifier+keysym combination.
Add another small method to cover that use case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2899>
Normally, mutter implicitly allows a window being shown to take
focus. This is normally desired, except it steals input from
GNOME Shell self. Avoid focusing the just shown window in those
situations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2878>
2d8fa26c8e ("core: Pass "frame action" grab operations as an
"unconstrained" grab op") changed the behaviour to treat non-grab
related window moving that has the "user action" flag set to still apply
the "constrain_titlebar_visible" constraint.
The fact that it wasn't applied before was relied upon by some
extensions. While it should arguably exist a better API that for such
extensions to use that have a bit more predictable behavior, until that
is so, restore the old semantics.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2891>
A Wayland client repeatedly requesting activation of its surface using
the xdg-activation protocol would make mutter constantly update the
cursor.
To avoid needlessly updating the cursor back and forth between busy and
default, add a timeout to delay the update.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2849>
Ensure we preserve the fast zero-copy paths in Xwayland fullscreen
windows, instead of maybe rendering the client surface on top of the
frame surface, and providing the latter to the compositor.
To achieve this, additionally synchronize frame state when
recalculating features (e.g. after fullscreen/unfullscreen), and
account for this new condition when creating or destroying frames.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2797>
These are done on the backend X11 connection, so it is unclear
what is the interplay through the borrowed global XSetErrorHandler()
that triggers issues for us here.
Anyways, better to be explicit, and use error traps the MetaBackendX11
style, in coherence with the rest of the things happening in that
display.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2864>
In order to make things more and more asynchronus and to each time we
paint be an isolated event, that can be potentially be applied
individually or together with other updates, make it so that each time
we draw, we use the transient MetaFrameNative (ClutterFrame) instance to
carry a KMS update for us.
For this to work, we also need to restructure how we apply mode sets.
Previously we'd amend the same KMS update each frame during mode set,
then after the last CRTC was composited, we'd apply the update that
contained updates for all CRTC.
Now each CRTC has its own KMS update, and instead we put them in a per
device table, and whenever we finished painting, we'll merge the new
update into any existing one, and then finally once all CRTCs have been
composited, we'll apply an update that contains all the mode sets for all
relevant CRTCs on a device.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2855>
This looks like a bug: There's no reason why windows which advertise
min-size hints that are exactly the size of the workarea should not be
allowed to maximize, so change the checks here to allow for that.
The commit message of 7f64d6b9 also makes the point that this was not
intended, as it says "larger than".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2873>
The introduction of the META_GRAB_OP_WINDOW_FLAG_UNCONSTRAINED
flag threw off some checks around keyboard-driven resize. This
was partly because there were some == checks that did not account
for that flag maybe being enabled, but also the handling
of META_GRAB_OP_KEYBOARD_RESIZING_UNKNOWN into a definite
resize direction was maybe unsetting that flag. Fix both things
at the same time.
Fixes: 2d8fa26c8e ("core: Pass "frame action" grab operations as an "unconstrained" grab op")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2629
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2871>
After !2489, the active workspace's MRU list is now used to pick
the next focus window instead of the stack order.
This list is currently only updated on focus, which can lead to
surprising behavior when closing a window after activating its
ShellApp in the shell.
That is because raising a window (as part of shell_app_activate())
will only change the stacking order, so when closing the active
app window, the focus will switch to whatever had focus before the
app was activated, not the app's next window.
In order to allow gnome-shell to address this, add a new
raise_and_make_recent() method that also adjust the MRU order.
https://gitlab.gnome.org/GNOME/mutter/-/issues/2540
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2866>
When modal dialogs are attached, and we set the parent/transient-for
after setting the modal type, the attachedness isn't updated. This is
(apparently) not the case for X11 windows, as they go through a
unmanage/manage dance avoiding the issue.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
The service channel D-Bus interface aims to be a "back door" for
services that needs special casing in Mutter, e.g. have custom private
protocols only meant to be used by that particular service.
There are currently no special casing implemented; only the basic
service channel infrastructure is added. There is a single method on the
interface, that is meant to eventually be used by
xdg-desktop-portal-gnome to open a Wayland connection with a private
protocol needed for the portal backend's rather special window
management needs.
The service channel Wayland client works by allowing one instance of
each "type", where each time needs to be defined to work in parallel. If
a new service client connects, the old one will be disconnected.
MetaWaylandClient's are used to manage the service clients, and are
assigned the service client type.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
On X11, the stage itself is backed by an XWindow, and moving the
input focus elsewhere will bypass any Clutter-level grabs.
This effectively allows newly opened windows to steal the focus
from gnome-shell itself, which is clearly undesirable. To prevent
that, only allow moving the X11 focus to a Window when no grab is
in place, just like commit 50e89e376 did for the stage focus.
But particularly the updating of x11_display->focus_xwindow is not
prevented. Since it's more consistent to the MetaDisplay/MetaX11Display
dual focus tracking and across Wayland/X11 backends, ensure the X11
input focus is actually set on the last focus Window after the
grabs are gone and windows became interactable again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2832>
This patch unfortunately results in situations where it is intended
that the focus change happens while a grab is present (e.g. Alt+tab
popup), resulting in confused focus state.
This commit is reverted in order to try a similar approach at a
different level.
This reverts commit 7531669b4f.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2832>
ClutterActions now no longer receive their events via
clutter_actor_event(), instead they get special treatment by the stage
now. Make the MetaGestureTracker work with this and stop emitting events
directly to Clutter via clutter_actor_event(), but instead let them get
through to Clutter (but still not to Wayland).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
The previous logic tried to keep the position of the top left corner of
the window relative to the top left corner of the monitor. This allowed
the window to move out of the target monitor. This change keeps the
proportions of the distance between the window and the monitor borders
instead if possible. Otherwise it keeps the relative position of the
center of the window clamped to [0,1] to make sure the window lands on
the right output.
This also slightly changes what monitor is considered to be on: the
monitor which contains the center of the window and, if the center is on
no monitor, the monitor wich overlaps the most with the window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2591>
At least indirectly, this is set as object qdata while the
window drag is ongoing, and reset/reconstructed if needed.
Consequently, this edge data does not need to be stored in
the MetaDisplay struct anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Even though the data is still stored in the display, add a "high
level" meta_window_drag_update_edges() call, so that the cached
edges may be updated while a window drag operation is ongoing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This is a public API change. Add device/sequence parameters to this
operation, so that window dragging and resizing can stick to one
set of pointing events of them all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Since MetaWindowDrag took a lot of this code to handle window drags
internally with less interactions with the rest of the stack, this
code in display/window/keybindings is unused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Flip the switch in using MetaWindowDrag, leaving display grab
ops and a bunch other code unused. Some places checked the grab op
and/or window in complex ways, others just checked for grab existence
and should now look for clutter ones, and others already were already
doing this in addition.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
We only allow partial grabs in the case of a keyboard-type MetaGrabOp
happening while the pointer cannot be grabbed. In that case, it's not
a big stretch to unconditionally ungrab the pointer device at the time
of undoing the grab, as it will be always ineffective (not even implicit
grabs on frame windows can happen now, inside Mutter).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This is no longer necessary, since the SSD frames are no longer
part of Mutter process, so it is not the MetaX11Display connection
which holds the implicit grab when a mouse button is pressed over
a window frame (say, to start a drag).
As the SSD frames client communicates the same way than CSD windows
for window operations, it is also expected to undo its implicit
grab before requesting a window move/resize operation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
The final effect of this boolean can now be expressed through the
META_GRAB_OP_WINDOW_FLAG_UNCONSTRAINED flag to MetaGrabOp. Use that
in the relevant places, and drop the argument.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Now that it is called from a single place, there's a few arguments
that are unnecessary:
- button and modifiers are unused
- already_grabbed was originally added to handle grab transitions between
window menus (GtkMenus, back in the day) with display grabs. It's no
longer necessary now
- frame_action can be passed through the META_GRAB_OP_WINDOW_FLAG UNCONSTRAINED
flag
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Leave meta_window_begin_grab_op() as the only public API to initiate
a display grab. There's no longer grab operations that don't attain
windows, and ending these grabs usually happen through user interaction
when the right circumstances happen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
There is no longer reason to call meta_display_begin_grab_op() except
for window grab operations, and meta_window_begin_grab_op() is a
perfectly fine entry point for all window grab operations.
Move away from meta_display_begin_grab_op().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
