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>
Currently, it is thought out to be called with META_GRAB_OP_KEYBOARD*
grab op parameters. Make it more generic so it can also be called for
pointer operations (avoiding pointer warping in that situation).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Unlike the comment suggests, this piece of event handling manages
the ungrabbing of a window on button press in the following 2
conditions:
- If a keyboard grab operation was triggered, the window does
additionally follow the pointer, and first button press ends
the grab.
- If a button-press grab is ongoing on the window, but more buttons
are pressed.
We can simplify this to just happen every time a button press event
is received while a window grab op is ongoing. The only case where
this might diverge a bit is same button presses from different
pointer devices, and it's not a big stretch to also undo the grab
in that situation.
This also happens to make the "button" argument in
meta_display_begin_grab_op() completely unused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
The frame_action boolean is only used by constraints.c code, in order to
determine whether a moving window should be able to move past the top
bar or not.
We can avoid the special casing by passing this information as a
META_GRAB_OP_WINDOW_FLAG_UNCONSTRAINED flag passed with the grab op.
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>
Make this public API check just return a boolean about whether
there is an existing grab, instead of exposing MetaGrabOp.
It is desirable to avoid exposing details like
META_GRAB_OP_WAYLAND_POPUP, so that MetaDisplay and wayland
grabs can port to ClutterGrab at their own pace, but also
this further information is unused.
This is likely to be temporary API anyways, after both
MetaDisplay and wayland grabs port to Clutter, it will be
possible to check the ClutterStage for all of them.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Rewrite this codepath so it handles the grab ops that it cares
about, and ignores the rest. This way the code works despite
possible future modifications to MetaGrabOp (e.g.
META_GRAB_OP_WAYLAND_POPUP removal).
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>
Some tests expect warnings to be logged, and handle that using
g_test_expect_message(). However, if debug topics are enabled, this
causes g_logv() to expect expected messages to also contain entries with
the debug level 'message' or higher to be listed in the expected message
list. Since meta_topic() always logged using g_message(), enabling debug
topics caused any test that used g_test_expect_message() and had debug
logging somewhere along the code path to fail.
Fix this by changing the log level of meta_topic() to 'debug' if we're
in a test. This doesn't mean they won't be visible, they still will
since debug log entries are printed by default during testing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2800>
These frames client will use a visual with alpha information, and
report the opaque frame shapes through the _NET_WM_OPAQUE_REGION
window property. We can use this information in the Mutter side
for accurate opaque shapes, despite X11 windows with frames now
being seen as possibly transparent.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2758>
If the window is unmapped or otherwise unmanaged while still existing,
we would fail to let the frames client follow up in destroying the
frame for the window.
Delete the _MUTTER_NEEDS_FRAME property, so that the frames client
can react to meta_window_destroy_frame(), this avoids stale invisible
frame windows for clients that simply unmap windows to reuse them
later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2791>
This XChangeWindowAttributes call was never surrounded by an error trap
and was not really expected to fail with BadWindow since the frame window
would be owned by Mutter itself.
This however is no longer true, and we might be getting a BadWindow from
the frame window given the right timing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2745>
Quoting Carlos:
The META_PRIORITY_EVENTS ± 1 happening below are in order to set these idles
and timeouts in a priority that is relative to the literal GDK event priority,
making those diverge is a likely way to sneakily break things.
But that's unlikely to happen, and decoupling mutter from GTK further
should make it moot, so perhaps it's alright after all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2407>
Clutter has an API to get the text direction but used to depend
on gtk3's translation domain. In order to avoid broken i18n
in case gtk3 is not installed, move the transtalable string to
clutter itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2407>
Things like meta_compositor_destroy() and meta_compositor_add_window()
isn't intended to be used externally, and if they was, things would
probably fall apart rather quickly.
MetaCompositor also isn't introspected, meaning things that technically
belong to the compositing parts isn't easily available via some object,
but much take detours via other objects like MetaDisplay.
So move the API intended for internal usage to compositor-private.h, and
leave API that is meant to be expose in the public compositor.h.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
The "later" API is used to queue actions in relation to compositing,
thus is owned by the MetaCompositor instance. Make users of this
functionality get MetaLaters instance from the compositor, and stop
using the global meta_later() API.
display: Use non-singleton MetaLater API
tests: Use non-singleton MetaLater API
meta/common: Make docs refer to context aware MetaLater API
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
The API has no concept of user data, and requires the user to some how
get an instance without context, i.e. via static globals. Limit this to
the file where this is needed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
As elsewhere, make sure objects that need to have a ownership up to the
context, and use this ownership chain to find relevant components, such
as the backend or the Wayland compositor object instance.
wayland/data-device: Hook up data devices to seats
They are tied to a seat - make that connection in struct fields too, so
that related objects can get to the context via it.
wayland: Don't get Wayland compositor via singleton getter
This means via the ownership chain or equivalent.
xwayland: Hook up manager to Wayland compositor
Same applies to the drag-n-drop struct.
xwayland: Make X11 event handling compositor instance aware
This avoids finding it via singletons in the callee.
xwayland: Don't get Wayland compositor from singleton
xwayland: Pass manager when handling dnd event
window/xwayland: Don't get Wayland compositor from singleton
xwayland/grab-keyboard: Don't get backend from singleton
xwayland: Don't get backend from singleton
wayland: Always get the backend from the context
This means traveling up the ownership chain or equivalent when
necessary.
wayland: Hook up data devices, offers and sources to the compositor
This allows tying them to a context without going through any
singletons.
wayland: Don't get display from singleton
xwayland: Don't get display from singleton
tablet: Don't get display from singleton
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
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>
This might happen when the workspace is not switched and
focus_default_window is called or when 'workspace on primary display
only' is enabled, a secondary display exists and the workspace is
switched.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2747>
There's 2 users of this, meta_display_sync_wayland_input_focus() which
does already perform these checks on its own, and MetaCursorTracker's
update_displayed_cursor() to determine whether it should go with the
Wayland client's cursor.
This second check should also consider the existing ClutterGrabs, so
make meta_display_windows_are_interactable() handle them for both
callers.
Fixes the cursor shown over windows while e.g. there are menus opened.
Close: https://gitlab.gnome.org/GNOME/mutter/-/issues/2553
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2754>
Let the frames client render its own shadow. In order to do that,
avoid double painting a shadow on the compositor side, and extend
the mask area of the frame, so it does unveil the (so far)
hidden frames-client-side shadows.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
