When setting a clear function on a GArray, unlike
most other places, this free func is expected to
*not* free the array element itself -- only its
contents.
Don't free the array element.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/2717
When the icon theme changes, we want to both initiate
a css SOURCE change (since css values may depend on the
icon theme), as well as calling gtk_system_setting_changed,
since widgets need to drop cached images, e.g. in GtkIconHelper.
When freeing the display GtkIconTheme and that was the last owner we
ran into a deadlock, because we unref the "next-to-last" ref inside a
gtk_icon_theme_ref_aquire/release() pair, which makes the final unref
to happen in the release(), while the ref lock still was held.
The unref triggers dispose which tries to NULL out the ref, but that then
deadlocks on the mutex being held by the caller already.
We fix this by moving the release unref outside the lock. This is safe
because refcounts are atomic, and we *do* own the ref.
Sprinkle various g_assert() around the code where gcc cannot figure out
on its own that a variable is not NULL and too much refactoring would be
needed to make it do that.
Also fix usage of g_assert_nonnull(x) to use g_assert(x) because the
first is not marked as G_GNUC_NORETURN because of course GTester
supports not aborting on aborts.
Add properties, and use string arrays instead of lists.
Among other things, this renames gtk_icon_theme_list_icons
to gtk_icon_theme_get_icon_names.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/2410
These don't take a duration, instead they call g_get_monotonic_time() to
and subtract the start time for it.
Almost all our calls are like this, and this makes the callsites clearer
and avoids inlining the clock call into the call site.
When we use if (GDK_PROFILER_IS_RUNNING) this means we get an
inlined if (FALSE) when the compiler support is not compiled in, which
gets rid of all the related code completely.
We also expand to G_UNLIKELY(gdk_profiler_is_running ()) in the supported
case which might cause somewhat better code generation.
usec is the scale of the monotonic timer which is where we get almost
all the times from. The only actual source of nsec is the opengl
GPU time (but who knows what the actual resulution of that is).
Changing this to usec allows us to get rid of " * 1000" in a *lot* of
places all over the codebase, which are ugly and confusing.
We test this by looking at the produced render nodes now that
we don't actualluy scale the icon. Also, it turns out that this
code was broken due to some typos, so we also fix those.
If you called gtk_icon_theme_lookup(), then always return some useful
icon name from gtk_icon_paintable_get_icon_name(), even if we picked
an unthemed icon.
Also rewrite the gtk_icon_paintable_get_icon_name() docs to make this
clearer.
Instead of having the IconTheme have a hashtable that owns
individual strings and then IconThemeDirSize have a similar
hash (but with the strings owned by the other hash), we
have a consecutive memory chunks where we store the icon names
and then the hashtable has pointers into this.
This means we can avoid a bunch of individual strdup()s in a
way that is less fragmented and wastes less space. Additionally,
since we do an initial lookup anyway we have the internalized
icon name during lookup which means we can use g_direct_hash/equal
instead of g_str_hash/equal making the lookup faster too.
If icon lookup fails or if loading it fails later, just always
fall back to the built in image-missing icon. Nobody is handling
missing icons in a sane way anyway.
If you *truly* need to handle missing icons, you need to manually
use gtk_icon_theme_has_icon().
While changing the loading code I also fixed an issue where it
was always passing "png" to pixbuf, now it also handles "xpm" if
that is the filename suffix.
We had a pretty complex setup where we tried to avoid scaling up themes from dirs
that specified a size. However, not only was it very complex, but it didn't quite
work with window scales, because when using e.g. a size 32 directory for 16@2x
the dir size is wrong anyway. Additionally it turns out most code either picks
an existing icon size, or uses the FORCE_SIZE flags, so it doesn't seem
like a useful behaviour.
This change drops the FORCE_SIZE flags, and always scales
icons. Additionally it moves the scaling of the icon to rendering,
which seems more modern, and allows us to (later) share icons loaded
for different sizes that happened to use the same source file (at
different scales).
Note that this changes the behaviour of
gtk_icon_paintable_download_texture() is it now returns the unscaled
source icon. However, ignore thats, as I plan to remove this function
and replace it with a way to render a paintable to a cairo-surface
instead.
It never makes sense to paint a texture that needs recoloring. If
you call the regular snapshot on a symbolic texture we just use the
default recoloring colors.
To support this we also change gtk_css_style_snapshot_icon_paintable()
to call gtk_icon_paintable_snapshot_with_colors() for IconPaintables
so that we get the correct colors, and we make it not emit the color
matrix.
Since we now rely on the icon to do the recoloring we also drop the
recolor argument in gtk_icon_paintable_snapshot_with_colors() as its
not needed anymore.
1. Rename the thing
2. Turn it from a signal to a vfunc
3. Pass the GtkCssStyleChange to it
We don't export any public API about the GtkCssStyleChange yet, it's
just a boring opaque struct.
Instead, rely on people passing fallbacks explicitly.
Alternatively, GThemedIcon provides the functionality to create
fallbacks, which is what GtkImage and the testsuite now use.
That method is slightly better, too, so the expected test results
have been updated accordingly.
There is no way to query contexts or do anything useful with them.
So don't keep track of them and don't make them an argument in public
APIs with the docs saying "I don't know what to use here, maybe read
some spec somewhere".
Those functions are unused and the documentation says "Returns some
random number that the icon theme creator chose" which does not seem at
all useful and an implementation detail.
So get rid of it.
We expose no API to get at any colors for drawing symbolics, so we
shouldn't have APIs to draw with them.
Apart from that, those APIs look like a box of crayons, not like an
icontheme.
