Previously we relied on the test-client to make sure that a window was
shown. For X11, we did not need to do anything, but for Wayland we had
to make sure we had drawn the first frame, otherwise mutter wouldn't
have a buffer making the window not showable.
Doing it this way doesn't work anymore however, since the 'after-paint'
event will be emitted even if we didn't actually paint anything. This is
the case with current Gtk under Wayland, where we won't draw until the
compositor has configured the surface. In effect, this mean we'll get a
dummy after-paint emission before the first frame is actually painted.
Instead, move the verification that a "show" command has completed by
having the test-runner wait for a "shown" signal on the window, which is
emitted in the end of meta_window_show(). This requires an additional
call to gdk_display_sync() in the test-client after creating the window,
to make sure that the window creation vents has been received in the
compositor.
As of "stack-tracker: Keep override redirect windows on top"
(e3d5bc077d), we always sorted all
override redirect on top of regular windows, as so is expected by
regular override redirect windows. This had an unwanted consequence,
however, which is that we should still not sort such override redirect
windows on top if they are behind the guard window, as that'd result in
windows hidden behind it now getting restacked anyway.
Fix this by only sorting the override redirect windows that are found
above the guard window on top. This fixes the override-redirect stacking
test.
The special ::pick implementation there makes clutter fall into paths
that do require a get_paint_volume() implementation, or an infinite
area will be used.
Providing a paint volume here is easier on the invalidation mechanism.
This optimization was presumably added before Clutter was able to
invalidate selected regions of an actor. Paint volumes are supposed
to be invariable as long as the actor conditions don't change.
Stacking of other actors shouldn't affect the paint volume, so it's
actually wrong to optimize those areas away here.
The framerate for screen cast sources was set to variable within 1 FPS
and the framerate of the monitor being screen casted. This meant that if
the sink didn't match the framerate (e.g. had a lower max framerate),
the formats would not match and a stream would not be established.
Allow letting the sink clamp the framerate range by setting it as
'unset', allowing it to be negotiated.
The PipeWire master branch saw some backports from the work branch,
including API changes making the 0.1 series more aligned with future
plans. Make mutter use the new API. This is needed to avoid dead locks
that existed in the older version.
xdg-foreign clears the `transient_for` of a modal dialog when its
imported parent is destroyed, which would later cause a crash in
`constrain_modal_dialog()` because the transient `NULL`.
So in case a modal dialog has no parent, do not try to constrain it
against its parent.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/174
The test fix in commit 859bea629b broke distcheck, probably because
abs_srcdir is prefixed with a relative $BUILDROOT. Hopefully this is
the last autotools breakage before switching to meson, so don't
bother investigating too much ...
Force update the cursor renderer after theme or size changes; otherwise
we'll be stuck with the old theme and/or size until something else
triggers resetting of the cursor.
MetaDisplay still had workspace signals, but nothing emitted them,
meaning we wouldn't get warnings if handlers were added there instead
of to MetaWorkspaceManager.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
If we wait with opening the X11 window decoration GDK connection, we
might end up with a terminated X11 server before we finish
initializing, depending on the things happening after spawning Xwayland
and before opening the MetaX11Dispaly. In gnome-shell, this involves
e.g. creating a couple of temporary X11 connections, and on disconnect,
if they happen to be the last client, the X server will terminate
itself.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Under Xorg the cursor size preference was pre-scaled originating from
gtk, while with Wayland it came directly from GSettings remaining
unscaled. Under Xwayland this caused the X11 display code to set the
wrong size with HiDPI configurations, which was often later overridden
by the equivalent code in gtk, but not always.
Fix this by always having the cursor size preference unscaled, scaling
the size correctly where it's used, depending on how it's used.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
GTK+ won't be initialized if X11 is not available
Instead, when setting gtk-shell-shows-app-menu,
meta_prefs_set_show_fallback_app_menu should be
called as well.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Allow removing a prefs handler that was already removed. This allows us
to remove prefs from the dispose function without having to keep track
of it in every place.
- Stop using CurrentTime, introduce META_CURRENT_TIME
- Use g_get_monotonic_time () instead of relying on an
X server running and making roundtrip to it
https://bugzilla.gnome.org/show_bug.cgi?id=759538
This moves following objects from MetaScreen to MetaDisplay
- workareas_later and in_fullscreen_later signals and functions
- startup_sequences signals and functions
- tile_preview functions
https://bugzilla.gnome.org/show_bug.cgi?id=759538
