In the future, the module will automate uploading the release
tarball. We already use the CI pipeline to generate the tarball,
so it's easy to hook up the module and provide some testing
before the module goes into production.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3775>
We currently assume that the `CI_COMMIT_TAG` variable matches the
version component of the generated dist tarball.
That is usually correct, but sometimes errors happen and a wrong
tag is pushed, and the real release uses something like "46.0-real".
Account for that by building the artifact path from `meson introspect`
and exporting it as environment variable.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3775>
For a Wayland only build, we would like to avoid linking against
libXcursor which on it turn, links back to some of the X11 deps.
In order to achieve that, we include a small subset of xcursor.
In case Mutter is built with X11 or with both Wayland & X11, we link
against libXcursor and don't make use of the in-tree implementation.
This patch mimics what GTK 4 do by shipping an in-tree copy of xcursor.
Especially that libwayland-cursor does not provide an alternative to
xcursor itself.
Helps #2272
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3607>
When meta_wayland_pointer_constraint_remove() is called, it can trigger
a meta_wayland_event_handler_invalidate_focus() via:
meta_wayland_pointer_constraint_destroy()
meta_wayland_pointer_constraint_disable()
meta_wayland_input_detach_event_handler()
meta_wayland_input_invalidate_all_focus()
meta_wayland_event_handler_invalidate_focus()
Which then would result in a "focus-surface-changed" signal which would
call meta_wayland_pointer_constraint_remove() a second time. This
happens after surface_remove_pointer_constraints() has already been
called in the first meta_wayland_pointer_constraint_remove() call,
leading to "data" being NULL.
To prevent this issue disconnect the signal handler before calling
meta_wayland_pointer_constraint_disable() when destroying a constraint.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3476
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3749>
In case of empty regions (e.g. when locking the pointer) the pointer
was only forced to stay within the boundaries of its current pixel
(i.e. culling subpixel position), instead of the position where the
pointer lock did start.
Fixes: 07d24fe50 ("backends/native: Allow infinitely small pointer constraint regions")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3749>
Since 07d24fe50 regions are not translated to their on-screen
coordinates anymore, but are relative to the origin stored in the
constraint. This origin however was not considered when checking whether
the pointer was within the constraint region. This meant that the
constraint region would appear to always be placed at 0,0 instead of on
the surface.
Fix this by using the cursor position relative to the origin.
Fixes: 07d24fe50 ("backends/native: Allow infinitely small pointer constraint regions")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3409
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3749>
We close wayland popups when a button or touch release happens outside
of the grab, except we don't want to close them when that button release is
actually the release of the press that was opening the grab in the first
place.
We never see the press event that opened the grab, so the first event we
see is actually always a release. Make sure to not close the popup on that
event, and instead only close the popup if we see the press count drop from
1 to 0.
This fixes a bug where popup would close right after they open. To
reproduce, click to open a popup, hold pressed and move the cursor over
shell chrome, then release. Or alternatively test with a popup that gets
opened with a long-press gesture (eg. long touch long press on libadwaita
tabs), just doing the touch long-press and then release.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3631>
Until this surface or its parent is finalized.
This makes sure that any `MetaWaylandSubsurfacePlacementOp` referencing
this surface for sibling will be applied as intended.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3737>
This reverts commit 35d92e0fac.
This turned out to cause trouble, because it can prevent
MetaWaylandSurface::applied_state.subsurface_branch_node from ever
getting linked up for a sub-surface.
It shouldn't be necessary anyway, since permanently_unmap_subsurface /
wl_subcompositor_get_subsurface reset the sub-surface state as defined
by the protocol.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3737>
GSettings overrides can be active and set the default value depending on
the XDG_CURRENT_DESKTOP environement variable. For the tests we run, we
rely on the default settings by using the GSettings memory backend but
we also need to make sure not overrides are in place.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3730>
because we want to switch between two workspaces. In some configurations
there is only a single workspace at this point so trying to get current
workspace + 1 gets us a NULL pointer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3730>
The internal representation of the min/max width of windows include what
is outside of the window geometry, so when the window geometry changes,
but the min/max size did not in the same commit, we'd be left with an
out of date min/max size, potentially causing windows to shrink when
configured.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3755>
local_error in meta_egl_query_device_string() is using g_autoptr,
meaning that it was getting freed after g_propagate_error(). This then
would result in error->message becoming invalid, causing crashes when
logging the error message later on.
Fixes: 8234f5bc7 ("egl: Return success status from meta_egl_query_device_string")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3758>
Just shovel the data through our own stdin/stdout, which will end up at
the right place (e.g. /dev/null).
This should hopefully solve `mutter-dist` failing due to a D-Bus method
call timeout in CI.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3757>
An action can be performed both on a signal emitted by a window or by
a well-known signal name, so that one can do:
[window-id]::signal => command
And so these would work:
w/1::position-changed => resize w/2 20 30
::monitors-changed => move w/1 30 40
We only support "monitors-changed" global signal name or connecting to
window signals for now, but this can be easily expanded adding support
for more global signal values or parsing other kinds of object instances
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3701>
Allows to use:
set_strut 0 0 MONITOR_WIDTH*0.5 MONITOR_HEIGHT/4 top [default]
We use the currently focused window as the reference monitor if any or
the primary one if no monitor is explicitly provided.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3701>
We may need to compare monitor size to fractions and while it can be
done using inverse divisions, they were not supported as we didn't parse
floating point values.
So, just add support for both multiplications and divisions, so that we
can easily do stuff like `MONITOR_HEIGHT*3/4`.
Additions would be easy to support too if we don't care about operator
priorities, but that's out of scope for now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3701>
We just made an half assed attempt to wait, but e.g. when clients were
waiting for a frame event, the attempt was not enough, as the clients
would not ack any configure until the time they were scheduled to paint
again.
Fix this by actually tracking newly pending configurations, and waiting
for them to return.
On X11, still be lazy and hope for the best, as there is no similar
configuration tracking there.
Some tests were updated to use just 'wait' when there was no actual need
for any extra waiting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3701>
When a window with an input shape on its decoration window becomes
undecorated and meta_window_x11_update_input_region() gets called via
notify::decorated, the buffer_rect of the window has not been updated
yet while the decorated property has. This would lead to us comparing
the input shape of the client window to the buffer_rect which still
includes the decoration window. This would fail to detect the common
case when the client window has no input shape set, leading to the input
region being set to the size of the client window rather than NULL. If
the window is then resized later, the input shape would remain at the
previous size.
This was not a problem before 6bd920b35, because then we were (wrongly)
always comparing to the client_rect.
Fix this by choosing the correct rect for comparison depending on
whether the window is decorated.
Fixes: 6bd920b35 ("x11/window: Use correct bounding rect to determine NULL input region")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3451
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3720>
