Prior to the grabs/focus rework in !3420, Wayland grabs were handled
separately from ClutterGrabs. This required explicitly checking for
ClutterGrabs as those were expected to prevent events from reaching
Wayland clients.
Now after !3420, Wayland client grabs also result in ClutterGrabs, which
means that this check causes input events for popups with grabs to not
get sent to ibus anymore. Instead the events are getting sent to the
client directly, which results no ibus support in popups (unless the
client handles that itself by using a different GTK_IM_MODULE).
However due to the changes from !3420 checking for ClutterGrabs is also
no longer necessary and the meta_wayland_text_input_update() focus check
is now sufficient to only forward events to ibus, when the focus is
actually on a Wayland client. So to fix this we can simply remove the
check.
Fixes: 2a584a8f0 ("wayland: Make use of Wayland event grabbing mechanism")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3502
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3787>
meta_window_handle_ungrabbed_event() triggers the show of the window menu in
gnome-shell via meta_window_show_menu() on hold of Meta + right mouse button
click.
Since meta_display_handle_event() was refactored lately and now forwards a
lot more events to Clutter (including the one triggering the window menu),
gnome-shell now sees this event after the menu has opened, figures that the
source-actor is outside of the menu, and immediately closes the menu again.
This is the correct behavior from the PopupMenuManager on the gnome-shell
side, it is the responsibility of the event handler that opens the menu (aka
meta_window_handle_ungrabbed_event()) to return CLUTTER_EVENT_STOP and stop
event propagation.
So fix this issue by adding a return value to
meta_window_handle_ungrabbed_event() and stopping event propagation in case
the event opened the window menu.
While at it, also return CLUTTER_EVENT_STOP for events triggering window
drags, so we can drop the extra check for that in
meta_display_handle_event().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3623>
With all early "goto out" paths bypassing wayland, we can pretty
much avoid the goto and use early returns in this function. This
will hopefully improve readability.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
This is Wayland specific code, handle it directly in MetaWaylandPointer.
This also fixes issues with the crossing event itself managing to reach
the window occluded by modals.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
Enable grabbing input for popups, and drag-and-drop. Since the very
switch to using ClutterGrab underneath Wayland grabs will challenge
assumptions in existing code, these had to change in one go. A notable
one is that meta_display_windows_are_interactable() is not 100% true
anymore for xdg_popups, at least not the same.
Another change happening in lockstep is MetaDnD no longer having
to funnel events to Wayland, since the grab triggered by Wayland DnD
is now a cause of "compositor grabs", and will naturally receive events
as long as it hold. while "modal".
A number of ad-hoc checks for grabbing state has also been dropped
from src/wayland/ internals, since again Wayland grabs are a reason
for Clutter grabs, plus the mechanism itself will already take care
of focus loss and restoration.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
In profilers with a timeline or flame graph views it is a very common
scenario that a span name must be displayed in an area too short to fit
it. In this case, profilers may implement automatic shortening to show
the most important part of the span name in the available area. This
makes it easier to tell what's going on without having to zoom all the
way in.
The current trace span names in Mutter don't really follow any system
and cannot really be shortened automatically.
The Tracy profiler shortens with C++ in mind. Consider an example C++
name:
SomeNamespace::SomeClass::some_method(args)
The method name is the most important part, and the arguments with the
class name will be cut if necessary in the order of importance.
This logic makes sence for other languages too, like Rust. I can see it
being implemented in other profilers like Sysprof, since it's generally
useful.
Hence, this commit adjusts our trace names to look like C++ and arrange
the parts of the name in the respective order of importance.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3402>
After an event has been handled such that it bypasses both Clutter and
Wayland, e.g. when handling a keybinding, bypass_clutter would get
unset in the presence of a wayland grab. This means that the event is
handled both as a keybinding and by Clutter.
In the case of switcher popups in gnome-shell in the presence of a gtk4
autohide popover this meant that instead of selecting the next element,
it would select the one after that. If there are only two elements, as
is common with input sources, this would mean going back to the current
one, preventing switching them with a single press of the keybinding.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6738
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3054>
This is something the compositor could now track by itself, instead of
being pushed through events. It also makes more sense to do this directly
when the grabbing conditions change, as opposed to the next event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3185>
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>
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>
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>
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>
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>
The whole reason for META_GRAB_OP_WAYLAND_POPUP to exist is to
avoid windows from being activatable/movable/resizable when a
grabbing xdg_popup is active.
Use the meta_display_is_grabbed() method which can tell this
from existing MetaWaylandCompositor grabs, so that this remains
true after dropping META_GRAB_OP_WAYLAND_POPUP.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This piece of event handling only applies on windows receiving events while
the display is ungrabbed (i.e. for raising it, or beginning a move/resize
operation).
Move the checks on the current grab operation outside of window.c and into
events.c, so all checks about the current grab operation move closer to the
main event handler.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
As with other parts, make objects have the ability to walk up the
ownership chain to the context, to get things like the Wayland
compositor or backend instances.
Contains these squashed commits:
display: Don't get backend from singleton
window: Don't get backend from singleton
keybindings: Don't get backend from singleton
workspace: Don't get backend from singleton
display: Don't get Wayland compositor from singleton
selection: Add display getter
context/main: Get backend directly from the context
clipboard-manager: Don't get display from singleton
stack-tracker: Don't use singleton MetaLater API
startup-notification: Hook up sequences and activations to display
This allows using context aware API directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
Replace the in-process implementation of frames with the external
frames client.
When a client window is created and managed by Mutter, Mutter will
determine whether it is a window that requires decorations and
hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME
property on the client window.
After the frames client created a window that has the _MUTTER_FRAME_FOR
property, Mutter will proceed to reparent the client window on the
frame window, and show them as a single unit.
Rendering and event handling on the frame window will be performed by
the external client, Mutter is still responsible for everything else,
namely resizing client and frame window in synchronization, and
managing updates on the MetaWindowActor.
In order to let the frame be managed by the external client, Mutter
needs to change the way some properties are forwarded to the client
and/or frame windows. Some properties are necessary to keep propagating
to the client window only, some others need to happen on the frame
window now, and some others needs to be propagated on both so they
are synchronized about the behavior.
Also, some events that were previously totally unexpected in frame
windows are now susceptible to happen, so must be allowed now.
MetaFrame in src/core/frame.c now acts as the wrapper of foreign
windows created by the frames client, from the Mutter side. Location,
size, and lifetime are still largely in control of Mutter, some
details like visible/invisible borders are obtained from the client
instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS
properties, respectively).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
The cursor rendering code path used by the screen cast code relies on
the cursor tracker machinery to determine where to blit the cursor
texture, but at the moment the cursor position invalidation is behind
a check for whether the shell is using a Wayland backend. (This code
path used to be Wayland-specific before 00cbcb7ba1 but has been
backend-agnostic since).
This commit removes the check for a Wayland compositor, allowing
cursor drawing to function correctly on X11 when screen casting in
embedded cursor mode.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1780
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2474>
We already bypass wayland if there is a ClutterGrab, so the case
that used to be covered by the event-route check is already handled,
and we can just remove the obsolete check.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
We use get_window_for_event() to check whether an event happened on top
of a window or on top of shell UI to decide whether to bypass delivering
the event to Clutter. In case of crossing events though, we can't just
use the device actor to determine whether to forward the event to
Clutter or not: We do want to forward CLUTTER_LEAVE events which
happened on top of shell UI. In that case the device actor is already a
window actor (the pointer already is on top of a window), but the shell
still needs to get the LEAVE crossing event.
Since the event source actor got removed from the detail of
ClutterEvent, the context we're looking for (which actor did the pointer
leave) is now the target actor that the event gets emitted to. Since the
last commit, we also made event filters aware of this context by passing
the target actor to them, so use this context now to determine whether
we're on top of a window or not.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2321>
We'll need the additional context of which actor the event will be
emitted to in mutters event filter (see next commit), so pass that
target actor to the event filters that are installed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2321>
Since the introduction of ClutterGrabs, MetaDnd now no longer gets
notified about input events on the stage during grabs (for example while
the alt-tab popup is shown) and thus can't move the grab feedback actor
anymore.
To fix this, forward events to MetaDnD directly from
meta_display_handle_event() when a ClutterGrab is in effect.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2308>
We get the MetaWaylandCompositor a bunch of times, but we can do with
getting it only once and then also replace the is_wayland_compositor()
checks with a if (wayland_compositor).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2308>
There may be situations where we may stack a ClutterGrab on top of a
wayland popup's. Since ClutterGrab should win over client grabs, we
mostly correctly figure out that it should start doing
bypass_wayland=TRUE and bypass_clutter=FALSE while the ClutterGrab
holds, however the late checks for the MetaDisplay event route can
still toggle bypass_clutter on, resulting in neither handling events.
This check for wayland popups in the display event route should just
enforce wayland handling if wayland is meant to be receiving events,
so ensure these don't mix together.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5020
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2271>
Wayland event processing and WM operations are themselves outside the
ClutterGrab loop so far. Until this is sorted out, these pieces of
event handling have got to learn to stay aside while there is a
ClutterGrab going on.
So, synchronize foci and other state when grabs come in or out, and
make it sure that Wayland event processing does not happen while
grabs happen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2099>
Change some things in these "app is alive" checks:
- The dialog timeout is separated from the ping timeout, in order
to show it again at a constant rate after dismissing, despite in
flight pings. It still shows immediately after the first failed
ping.
- As we want to tap further into is-alive logic, MetaWindow now
made it a property, that other places in code can fetch and
subscribe.
- Motion events trigger ping (as long as there was none other in
flight for the same window), and are counted between ping and
pong, in order to preemptively declare the window as not alive
before there is trouble with event queues being overflown.
This results in a separate logic between "the application does
not respond" and "we are showing the close dialog" so that the
former may get triggered independently.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2122>
