_clutter_actor_get_animation_info() creates a new info when the actor
currently doesn't have one. That's unnecessary and wasteful in case
where we only need to check for transitions to remove, so switch to
_clutter_actor_get_animation_info_or_default() that falls back to
an empty static info.
Fixes: c250f602bd ("clutter/actor: Remove transitions when removing an effect")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4260>
If there are any in-progress transitions on any properties of the
effect, these will cause a crash next time they tick and update, as they
will try to access a `@effects.${effect_name}.${property_name}` property
on the `ClutterActor` which no longer resolves to an effect. In some
cases this will be because `priv->effects` itself is now `NULL` on the
`ClutterActor`.
This can be triggered by rapidly toggling screen time limits on and off
in gnome-shell with a low screen time limit which has already been
reached for the day. It will alternately add a desaturation effect and
fade-in transition, then remove the effect, then the transition will
update and crash.
Avoid this by removing relevant transitions when removing an effect.
Do the same for the other two groups of metas: constraints and actions,
as they will be subject to the same bug (under different reproducer
conditions). And the same for when any of these three meta groups are
cleared, as that could also trigger the same bug.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8168
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4222>
Currently, this has been living in StWidget, moving that to Clutter
allows us to properly track the accessibility state changes in the
actors provided inside Clutter as well as simplifying things for a
future move from Atk.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4089>
Allowing to disable font rendering integration, making it possible to
build Mutter without pango/harfbuzz/fribidi dependencies.
This commit also adds a new clutter-pango header that is used to include
pango specific bits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4106>
When the `org.gnome.desktop.interface` schema is not found, currently
we were not initializing the font_options which means we needed to
handle that on the backend side. Instead, generate the font_options at
that moment.
As the settings are loaded the moment we assign a backend to the
settings `_clutter_settings_set_backend` which is called just after the
backend is constructed which is too early for any actor to use it for
creating a PangoContext, so the change is safe.
Also, as the font_options getter is only used in ClutterActor when
creating the PangoContext, drop the getter. As we might just store that
info somewhere else in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4106>
Following previous commit, rename _clutter_paint_volume_init_static()
to clutter_paint_volume_init_from_actor(), and also
_clutter_paint_volume_copy_static() to
clutter_paint_volume_init_from_paint_volume().
Make clutter_paint_volume_init_from_paint_volume() follow the dst/src
semantic in its arguments, which also allows removing
_clutter_paint_volume_set_from_volume() which is exactly the same now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4175>
And change clutter_paint_volume_free() to always free the paint volume.
Remove all calls to clutter_paint_volume_free() on static variables.
Having to call a free function on a static variable always seemed a bit
odd, and this genuinely confuses Coverity (and me).
Coverity CID: #1505838
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4175>
As that is where the whole text rendering integration happens
And would allow us to get rid of some over-abstraction in cogl-pango,
simplify
ClutterSnapshot integration as well
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4004>
Instead of duplicating a string we own already we can just steal it from
the array that we're using.
This is safe since we're sure about the tokens GStrv length and we are
always stealing the last element, so there is no risk that g_strfreev
would eventually leak something.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4071>
Quoting Ebassi https://www.bassi.io/articles/2023/02/20/bindable-api-2023/:
Whenever you’re describing a function that takes a callback, you
should always annotate the callback argument with the argument that
contains the user data using the (closure argument) annotation
You should not annotate the data argument with a unary (closure).
The unary (closure) is meant to be used when annotating the callback
type
Recently gobject-introspection became a bit more strict with this and
that generated some warnings:
Warning: Cogl: invalid "closure" annotation: only valid on callback
parameters
This commit fix all the closure annotations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4058>
Instead, get it from the context. See next commit
For ClutterText, we had to switch to using constructed
as the ClutterContext will be set for the ClutterActor in the
constructor phase
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3977>
Currently, we would only disable a11y if a certain flag is passed
but the function is always called with NONE flag. Instead
drop the flag, use a new environment variable for that
That value is then used by actors to short-circuit get_accessible
implementation and return NULL if the accessibility is not enabled
Also clean the other accessibility functions
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3917>
As they are better fit in ClutterActor
The accessible_role is intentionally put in the public fields
as ClutterActorAccessible needs access to that without going
in recursion
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3917>
The initial target color state is the color state of the stage view
being painted to. If we're painting to an arbitrary framebuffer, it's
currently hard coded to sRGB/electrical.
The content color state is not set on construction, but when starting to
paint, it's set to the color state of the stage itself. Whenever an
actor is painted, it'll set the color state to the color state of
itself. The intention is that offscreen rendering pushes a target color
state that causes painting to it to not necessarily be in the stage view
color state.
Pass color state with offscreen framebuffer, as this avoids hard coding
sRGB in the lower level bits of paint contexts. It's still practically
hard coded, only that it's derived from somewhere else (e.g. the stage
or window actor).
Nothing is actually using this yet, but will eventually.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
The context can be set via a property (currently unused) or via the
current global singleton as a fallback. It means API that acts on an
actor can avoid going via any globals.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
This is conditionally toggled by grabs on the current key focus depending
on whether the current key focus actor would receive events according
to the grab or not. Which means it's no longer a reliable method for an
actor to know it does have focus, without asking the stage about it.
Avoid this check and ask the stage for the key focus, in order to make
key focus actors able to unset themselves despite the presence of grabs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3629>
