We haven't had any scalable directories in this list.
Add some. Since we seem to have settled on including
just actions and status as subdirectories for each
size, add scalable/actions and scalable/status.
Fixes: #4960
Those property features don't seem to be in use anywhere.
They are redundant since the docs cover the same information
and more. They also created unnecessary translation work.
Closes#4904
We were going via GLoadablieIcon/GInputStream for everything previously
and we have no API for that with GdkTexture.
With this commit, gdk-pixbuf isn't used anymore when starting
widget-factory for anything but SVG.
Remove a boatload of "or %NULL" from nullable parameters
and return values. gi-docgen generates suitable text from
the annotation that we don't need to duplicate.
This adds a few missing nullable annotations too.
Add a utility function to check whether the icontheme
will produce something better than missing-image for
a GIcon. Obviously, we can only answer this question
if the GIcon is a themed icon the begin with.
Add a paragraph to the migration guide that explains
how to properly render symbolic GtkIconPaintables.
Also mention this in the GtkIconPaintable docs.
There's a reason you can't spell 'paintable' without
'pain'...
We require a C compiler supporting C99 now. The main purpose of
these fallbacks was for MSVC. From what I can see this is now all supported
by MSVC 2015+ anyway.
The only other change this includes is to replace isnanf() with the
(type infering) C99 isnan() macro, because MSVC doesn't provide isnanf().
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.
