The ID is required for the wayland protocol. In the future we might want
to spend a bit more effort to re-use existing color states when a new
one is requested and also try to re-use IDs instead of just counting up.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3897>
This means the pipeline can be manipulated after retrieving. This also
fixes a leak when adding pipelines to the cache, as we the pipeline
would take a ref, but when adding, we wouldn't clean up our own ref.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3897>
As the only info we can pass now is whether we have any idle
closures. Removes the timeout handling which is now is always set to
either 0 or -1 based on whether we have idle closures
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3887>
The drm subsystem has been moving over to gitlab for some time now and
the old anongit.freedesktop.org remote is becoming unusable. Contains
the same repo with the same tags, so this shouldn't result in any
differences.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3896>
According to gmacros.h, G_STATIC_ASSERT is undefined for __GI_SCANNER__
because it causes confusion. Which is understandable, and so is the
complaint about the lingering G_STATIC_ASSERT after preprocessing.
This problem seems to be unique to just clutter-deform-effect.h because
it's the only header file containing a top-level G_STATIC_ASSERT. The
rest are all in C files.
Fixes: 138e5d4f54
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3591
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3898>
Having an always-on-top window affects focus granting logic if the
to be showing window overlaps with any of them. Instead of triggering
the focus denying logic if a new window ever so slightly touches an
always-on-top window to only triggering if it's covered more than 60% by
always-on-top windows.
This is intended to make using always-on-top windows a bit less annoying
and not cause as many unintended focus-on-map denials.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3879>
When we show a window, we'll check if it overlaps with an existing
always-on-top window with the intention to deny focus. However, we did
this potentially before having placed the window, meaning we effectively
checked as if it was placed at (0, 0), which created unexpected results.
Instead check the overlap state after placing. A window placement test
case is added to verify this works as expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3879>
Replace a boolean argument and a temporary MetaWindow struct field with
a `MetaPlaceFlag` passed where relevant. This includes
`meta_window_move_resize_internal()` and `meta_window_constrain()`, as
placement may happen during constraining, and also
`meta_window_force_placement()`.
The struct field (denied_focus_and_not_transient) was only ever set in
meta_window_show(), before meta_window_force_placement(), and
immediately unset as a side effect of that. In .._show() we'll always
force placement if the window wasn't already placed, and in
meta_window_constrain(), we'd only ever call meta_window_place() if the
window wasn't already placed, meaning the variable would only ever be
relevant during `meta_window_show()`. Having it as a flag makes that
relationship and temporary state clearer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3879>
The function checking whether a 'always-on-top' window covers the
showing window now has that in the name, to make it more obvious. That
function was also changed to use the more common way of iterating a
list, and now uses auto cleanup pointers for the list.
The condition itself was updated to follow the current coding style.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3879>
Not sure it makes sense to translate only parts of the debugging output
and on top of that, those files were not part of POTFILES, so they were not
translated anyways..
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3895>
It won't be used until later when we flip, and in fact assigning
it early could have led to its own assertion failing on the next frame
in the unlikely event that we return with "Failed to ensure KMS FB ID...
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3891>
This avoids the following critical warning happening sometimes when a
Wayland client exits taking all its window with it in an arbitrary
order:
CRITICAL: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3870>
This, in contrast to 'assert_stacking' only checks showing windows. This
is useful when doing workspace tests, where one want to check what
windows are currently visible.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3870>
When a transient window becomes transient, check if the parent is
sticky, and if it is, make the transient sticky as well. This handles
situations where e.g. a utility dialog (such as search and replace) is
opened on a sticky window, also making the utility dialog sharing the
same stickyness state.
This is also more in line with the semantics of making a window sticky,
where transient would implicitly become sticky as a side effect.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3870>
If a transient window is sticky (visible on all workspaces) and it gets
activated, we'd call move_worskpace() which would effectively unstick
it, which is rather unexpected. It'd also effectively unstick its parent
as well, due to moving a transient window also moves its descendants and
ascendants.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3870>
Introduced in libinput 1.26 this feature allows restricting the
tablet tool pressure range to a subset of its physical range. The
use-case is either to require some higher-than-usual minimum pressure
before the pen reacts, or lower-than-usual pressure to reach the maximum
logical pressure.
libinput takes a [0.0, 1.0] normalized range which we expose as percent
in the gsettings. The wacom driver doesn't have an exact equivalent but
it has a Threshold setting (range [1, 2048]) that defines when a button
is generated for tip down.
See gsettings-desktop-schemas!84
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3794>
