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>
