Assigning the corresponding stack layer of DOCK windows is currently X11
specific, because there is no way for wayland clients to set the DOCK
window type. This is about to change, so move the code to the generic
layer handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3612>
MetaWindow always tries to have a main monitor: If the frame rect is empty
and the window has not been positioned, in meta_window_constructed() we fall
back to asking the backend for the current monitor, and in
meta_window_wayland_update_main_monitor() we fall back to
meta_window_find_monitor_from_id(), which then falls back to the primary
monitor.
In general this means that window->monitor is always set as long as there is
a monitor around.
For getting the highest-scale-monitor the window is on, we currently rely
completely on the frame rect. If the frame rect is empty, we set the
highest-scale-monitor to NULL. Since we usually know though which monitor
the window is, or will be on, and window->monitor is even set to that, we
can just fall back to window->monitor for the highest-scale-monitor.
This makes sure ::highest-scale-monitor-changed is emitted right after the
window is created, and it's set to the correct monitor that the window will
be on. This in turn means that we can send a correct wp_fractional_scale
fraction_scale event to clients right away.
https://gitlab.gnome.org/GNOME/mutter/-/issues/3262
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3598>
The function was used only once so just move it content where it is
called. It allows us to drop more cairo paths from the API surface even
if it is not part of a public api
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3581>
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>
Except meta_window_x11_get_group, which is still used by GNOME Shell
and we can't make it a private API for now.
Will need further investigation and could be done as a future
step
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3555>
The macro used to call into a bunch of other macros so let us turn it
into a single function.
This would simplify things for the next commit that puts the MetaGroup
usage behind a X11 ifdef
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3555>
A ring will naturally go from 355 degrees to 5 degrees (or vice versa),
giving us the illusion of a direction change. Avoid this by assuming
that any change larger than 180 degrees is actually the equivalent
smaller change in the other direction.
Closes#1885
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3545>
Transient dialogs are meant to be placed centered over their
parent. However as we don't use the DIALOG window type on
wayland, this currently only works for modal dialogs.
To fix this, also apply the policy to NORMAL windows for
wayland clients.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3533>
Instead of letting the MetaDisplay be aware of the Wayland compositor,
and take care of updating its focus. This makes the MetaWaylandCompositor
able to track focus changes by itself, using MetaDisplay as the source
of truth.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3511>
