Avoids exposing the former in the next commit even if MtkRectangle
uses signed integers compared to RectangleMapEntry. But as
those rectangles are defined inside of Cogl, it should be okay
I guess?
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3909>
The OpenGL specs say rounding is preferred, but not required. Let's
avoid that uncertainty by choosing a test value that rounds and truncates
to the same integer either way. Only green needs fixing since our red,
blue and alpha values already follow this rule.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3903>
Simply to make it clear that the renamed function is specific to a
particular X11 initialization mode (mandatory Xwayland), put that in the
name, so that it's easier to understand when this function is relevant.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3329>
This means that for X11 sessions we'll do it before any windows are
mapped, and before any plugin implementation is started. Doing it before
a plugin is started is important, because things that the plugin does
during startup can have consequences on how compositing on Xorg works.
For the Xwayland case, we'll do it relatively in the setup phase. It
appears to have been harmless to do it later in the post-opened signal,
but there is no harm in doing it as one of the earlier steps.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3089
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3329>
by executing `global.context.get_debug_control().exported = true`.
This makes it possible to get access to the debug service without having
to start with `--enable-debug`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3902>
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>
