GThemedIcon considers the "-symbolic" suffix when generating
fallback names (i.e. "foo-bar-symbolic", "foo-symbolic", "foo-bar",
"foo").
That means now that we prefer more accurate name matches from any
theme over fallback matches from higher-priority themes, we no
longer need to special-case symbolic names for preferring symbolic
matches over full-color fallbacks.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2824>
When resolving an icon name, we currently look in all themes in
order whether one of the requested names matches.
That means, a "keyboard" icon from the configured theme will
trump over any of "keyboard-shift", "keyboard-brightness" and
"keyboard-preferences" from lower-ranked themes (like "Adwaita"
and "hicolor").
That applies to custom icons we include in the resource, which
are added to the fallback ("hicolor") theme.
We are less bound by the named-icons spec than GTK, so we can
adapt the lookup to prefer the most accurate match to matches
from the highest priority theme.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2824>
When using fractional scaling, the size of the loaded image with
applied scaling may still differ from the displayed size. This
is currently addressed by syncing the size of all slice actors
in the (probably only) caller.
Instead, set the actors to fill their parent automatically.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2798>
This is a small one time leak if there is more than one entry in the
search path due to multiple iterations overwriting the old pointer
before finally going out of scope.
Fixes: 934faaace ("st/icon-theme: Start using g_autofree")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2737>
When loading a symbolic SVG, the original file is wrapped in
a header that includes a generated stylesheet with the
appropriate colors, plus an overall opacity.
The opacity value is clamped to values between 0 and 1, which
directly matched the alpha field of the GdkRGBA type. However
since we moved to StIconColors/ClutterColor, the alpha field
is now in the range [0..255], any alpha value other than 0 now
results in full opacity.
To fix, translate the [0..255] integer into a [0..1] double
before using it as opacity.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2731>
Add common test environment variables to a default test setup so that they
don't need to be repeated everywhere.
Also ensures that we're always using the gsettings memory backend to never
interfere with local environment.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2661>
St has been stuck at version 1.0, which makes it difficult to
version API documentation.
Configure it to build with the same namespace version as
Mutter, so documentation and API changes can be tracked.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2674>
StIconTheme was added as a private implementation detail of
StTextureCache, but it turns out that some extensions do
make heavy use of GtkIconTheme.
Allow them to port away from GTK by exposing StIconTheme to
introspection.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2671>
There's a few things going on here, that unfortunately must
happen in lockstep:
- The gnome-desktop-3.0 dependency gets replaced by gnome-desktop-4
and gnome-bg-4. The code in ui/background.js required minor updates.
- The libnma dependency gets replaced by a libnma4 dependency. The
code in misc/modemManager.js required minor updates.
- The gtk3 dependency is torn down everywhere but tests. Some
missing GdkPixbuf dependencies had to be added to compensate for
its lack.
- gtk_init_check() is no longer called
As a result, we replace a hard gtk3 dependency with a soft gtk4
run-time linking one, only added indirectly through gnome-bg-4
and libnma4.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2655>
Avoid using it by... guess it... yes! Copying the function
into an utility. This helper function to convert between
pixel formats is quite self-contained and unrelated to the
rest of GTK, so may be copied in place.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2655>
We already have ClutterColor to represent a color, and StIconColors
to hold color information for symbolics from CSS. Now that we moved
GtkIconTheme in-tree, we can make use of those types instead of
translating back and forth from GdkRGBA.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
We are still linking to GTK, and extensions may import GTK for
whatever reason, so avoid conflicts by moving the copied GTK
code into our namespace.
With that and the previous adjustments, the new code is now
finally buildable.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
Its use has been discouraged for years, and glib recently deprecated
it officially (while turning it around a small wrapper around malloc).
Don't let it sneak back in through some old GTK3 code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
The GTK code predates the G_DECLARE_*() macros, so it's under- standable
that it still does all the boilerplate manually. We
don't have that excuse in 2023, so move the the standard macros.
There is no reason for GtkIconTheme to be derivable, and as that
means that the instance struct itself is private, stop adding
separate private instance data.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
GTK uses its own private i18n header, which most notably defines
an I_() macro for interning static strings. That may be a worthwhile
idea for the entire codebase, but as it's out of scope for this
change set, just use the standard i18n support from glib for now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
Those are GTK internals that don't apply to us. Without the distinct
"screen's default icon theme", we also don't need custom theme support,
and can just always track the theme from StSettings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
The GTK code dates back to a time when "gchar" and friends were
still considered a good idea. Replace them with standard types
except for "guint" (I'm lazy) and GtkIconCache code that relies
on glib's byte order macros.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
GtkIconTheme's headers are split between a public and a private
one. We won't expose the icon theme API at all, nor do we need
to access anything beyond what the texture cache is currently
using, so merge the private header into the implementation.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
GTK4 changed icon loading significantly, it is now closely tied
to snapshots and paintables. This makes a port highly unrealistic,
so to avoid staying stuck on GTK3 forever, copy the relevant code
into the tree.
The code is unmodified except for the include names and replacing
some stray tab indentation. It is still full of GTK internals, so
it will take a while before we can actually build it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
Commit 9168f6055e marked the parameter as nullable, which is in
conflict with the precondition check. But given that NULL is
valid for the underlying ClutterText (and GtkLabel accepts it
as well), there's no strong argument for disallowing NULL, so
remove the precondition check.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2465>
Only when part of it is actually visible.
Because the central rectangle is generally the largest part, this
eliminates most of the shadow's render time. For example, animating
`.workspace-background` by tapping Super, the shell's overall render
time is reduced about 15%.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1915>
