MetaSelectionSourceMemory currently uses GBytes for its underlying data.
This can cause memory overhead when large items, such as HD images, are
stored in the clipboard. This commit changes the underlying data
structure to a MetaAnonymousFile object, which writes to memfd instead
of heap. When reading, MetaSelectionSourceMemory will create a
Gio.UnixInputStream from the file descriptor generated by
MetaAnonymousFile. We subclass the UnixInputStream as
MetaUnixInputStream, to override the stream's close_fn function so
that it invokes meta_anonymous_file_close_fd when the stream terminates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3551>
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>
`meta_window_set_user_time()` will not update the window's
user time if it timestamp in the argument is before the
currently saved timestamp. However, when trying to work around
problematic timestamps, this is exactly what needs to be done.
So force the update to happen by setting the "is user time set?"
flag to false.
Fixes: 8f3da9f68a10ff ("Use meta_window_set_user_time for setting user time consistently")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3027>
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>
