GtkIconInfo contains too much redundant data,
and it is hard to know which fields are to be
used when.
This commit starts to move towards dropping the
icon_file field - we prefer to work with the
filename directly, since it lets us avoid mime
sniffing and strdups.
This function is not useful. Every icon theme
on my system either does not have that field,
or has it as 'folder'. So, just use 'folder'
when you need an example icon.
Add a cache of icon infos that we keep around a little longer, to avoid
loading icons from disk that only exist for a short amount of time (e.g.
during one frame of a cell renderer snapshot).
We make sure recently used items are kept alive by just adding them to
the cache on lookup.
We were allocating IconThemeDir instances and then only later assign a
value to has_icons. In the !has_icons case, we were directly throwing
the IconThemeDir away again.
Delay allocating the IconThemeDirs until we know that it has icons.
This avoids allocating and then de-allocating around 1400 IconThemeDir
instances when opening the widget-factory.
The previous code was hiding the fact that the scan_resources function
almost always did nothing and just used g_resources_enumerate_children()
and then returned FALSE, leaving the caller with cleaning up the already
allocated IconThemeDir. By inlining this, we make sure that calling code
does not even need to allocate the IconThemeDir.
We call this function *a lot* it's doing lots of unnecessary work inside
g_str_has_suffix. Get the icon name length only once instead and
open-code the suffix check.
When loading a SVG icon from a gresource file only containing SVG icons,
but without having a SVG loader available in gdk-pixbuf, we would crash
when trying to eventually load the resource. Fix this by gracefully
handling this by simply failing to load the icon, while the first time
it happens, log a warning.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/2084
If we set c_marshaller manually, then g_signal_newv() will not setup a
va_marshaller for us. However, if we provide c_marshaller as NULL, it will
setup both the c_marshaller (to g_cclosure_marshal_VOID__VOID) and
va_marshaller (to g_cclosure_marshal_VOID__VOIDv) for us.
We wrap SVG data from icons within another SVG with extra styling
information. The wrapped SVG may contain characters that cannot be
part of a data: URL (https://fetch.spec.whatwg.org/#data-urls).
Librsvg 2.45 got more strict in its parsing of data: URLs; whereas
previously it ignored '#' characters in them, now it considers them to
be the start of a fragment identifier, which is not allowed in data:
URLs anyway.
To avoid unallowed characters, we now create a data: URL with a
base-64 encoded SVG.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1471
This renames the GdkWindow class and related classes (impl, backend
subclasses) to surface. Additionally it renames related types:
GdkWindowAttr, GdkWindowPaint, GdkWindowWindowClass, GdkWindowType,
GdkWindowTypeHint, GdkWindowHints, GdkWindowState, GdkWindowEdge
This is an automatic conversion using the below commands:
git sed -f g GdkWindowWindowClass GdkSurfaceSurfaceClass
git sed -f g GdkWindow GdkSurface
git sed -f g "gdk_window\([ _\(\),;]\|$\)" "gdk_surface\1" # Avoid hitting gdk_windowing
git sed -f g "GDK_WINDOW\([ _\(]\|$\)" "GDK_SURFACE\1" # Avoid hitting GDK_WINDOWING
git sed "GDK_\([A-Z]*\)IS_WINDOW\([_ (]\|$\)" "GDK_\1IS_SURFACE\2"
git sed GDK_TYPE_WINDOW GDK_TYPE_SURFACE
git sed -f g GdkPointerWindowInfo GdkPointerSurfaceInfo
git sed -f g "BROADWAY_WINDOW" "BROADWAY_SURFACE"
git sed -f g "broadway_window" "broadway_surface"
git sed -f g "BroadwayWindow" "BroadwaySurface"
git sed -f g "WAYLAND_WINDOW" "WAYLAND_SURFACE"
git sed -f g "wayland_window" "wayland_surface"
git sed -f g "WaylandWindow" "WaylandSurface"
git sed -f g "X11_WINDOW" "X11_SURFACE"
git sed -f g "x11_window" "x11_surface"
git sed -f g "X11Window" "X11Surface"
git sed -f g "WIN32_WINDOW" "WIN32_SURFACE"
git sed -f g "win32_window" "win32_surface"
git sed -f g "Win32Window" "Win32Surface"
git sed -f g "QUARTZ_WINDOW" "QUARTZ_SURFACE"
git sed -f g "quartz_window" "quartz_surface"
git sed -f g "QuartzWindow" "QuartzSurface"
git checkout NEWS* po-properties
Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
The main GDK thread lock is not portable and deprecated.
The only reason why gdk_threads_add_idle() and
gdk_threads_add_idle_full() exist is to allow invoking a callback with
the GDK lock held, in case 3rd party libraries still use the deprecated
gdk_threads_enter()/gdk_threads_leave() API.
Since we're removing the GDK lock, and we're releasing a new major API,
such code cannot exist any more; this means we can use the GLib API for
installing idle callbacks.
https://bugzilla.gnome.org/show_bug.cgi?id=793124
g_resources_enumerate_children expects the path to end
in a '/' (even though thats not stated in the docs), and
will copy it if that isn't the case. Avoid the copy
by putting a '/' there to begin with.
With the shader approach to symbolic recoloring, we must
not recolor the svgs anymore as we're loading them. Instead,
load them the same way that gtk-encode-symbolic-svg does.
This fixes the rendering of large symbolic icons e.g. the
'no search results found' page in the file chooser.
This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
On windows you might not have a theme installed by default which
means that when trying to create the context quark it will fail.
If then we try to replace a NULL key in the hash table it will crash.
https://bugzilla.gnome.org/show_bug.cgi?id=769859
Use a static array for the known icon sizes, now that we don't allow
registering custom icon sizes any more. This allows us to cut a one-off
allocation that makes Valgrind sad.
13 bytes in 1 blocks are definitely lost in loss record 766 of 16,875
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0xA9D0247: vasprintf (in /usr/lib64/libc-2.24.so)
by 0xA2453FC: g_vasprintf (gprintf.c:316)
by 0xA2152F7: g_strdup_vprintf (gstrfuncs.c:514)
by 0xA21539C: g_strdup_printf (gstrfuncs.c:540)
by 0x678F25C: gdk_rgba_to_string (gdkrgba.c:360)
by 0x5FAE00D: rgba_to_string_noalpha (gtkicontheme.c:4322)
by 0x5FAE6F2: gtk_icon_info_load_symbolic_svg (gtkicontheme.c:4492)
by 0x5FAED4F: gtk_icon_info_load_symbolic_internal (gtkicontheme.c:4622)
by 0x5FAEEE8: gtk_icon_info_load_symbolic (gtkicontheme.c:4711)
by 0x5F00246: gtk_css_image_recolor_load (gtkcssimagerecolor.c:118)
by 0x5F003E4: gtk_css_image_recolor_compute (gtkcssimagerecolor.c:170)
14 bytes in 1 blocks are definitely lost in loss record 801 of 16,875
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0xA9D0247: vasprintf (in /usr/lib64/libc-2.24.so)
by 0xA2453FC: g_vasprintf (gprintf.c:316)
by 0xA2152F7: g_strdup_vprintf (gstrfuncs.c:514)
by 0xA21539C: g_strdup_printf (gstrfuncs.c:540)
by 0x678F25C: gdk_rgba_to_string (gdkrgba.c:360)
by 0x5FAE00D: rgba_to_string_noalpha (gtkicontheme.c:4322)
by 0x5FAE68E: gtk_icon_info_load_symbolic_svg (gtkicontheme.c:4482)
by 0x5FAED4F: gtk_icon_info_load_symbolic_internal (gtkicontheme.c:4622)
by 0x5FAEEE8: gtk_icon_info_load_symbolic (gtkicontheme.c:4711)
by 0x5F00246: gtk_css_image_recolor_load (gtkcssimagerecolor.c:118)
by 0x5F003E4: gtk_css_image_recolor_compute (gtkcssimagerecolor.c:170)
15 bytes in 1 blocks are definitely lost in loss record 838 of 16,875
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0xA9D0247: vasprintf (in /usr/lib64/libc-2.24.so)
by 0xA2453FC: g_vasprintf (gprintf.c:316)
by 0xA2152F7: g_strdup_vprintf (gstrfuncs.c:514)
by 0xA21539C: g_strdup_printf (gstrfuncs.c:540)
by 0x678F25C: gdk_rgba_to_string (gdkrgba.c:360)
by 0x5FAE00D: rgba_to_string_noalpha (gtkicontheme.c:4322)
by 0x5FAE6C3: gtk_icon_info_load_symbolic_svg (gtkicontheme.c:4487)
by 0x5FAED4F: gtk_icon_info_load_symbolic_internal (gtkicontheme.c:4622)
by 0x5FAEEE8: gtk_icon_info_load_symbolic (gtkicontheme.c:4711)
by 0x5F00246: gtk_css_image_recolor_load (gtkcssimagerecolor.c:118)
by 0x5F003E4: gtk_css_image_recolor_compute (gtkcssimagerecolor.c:170)
16,384 bytes in 1 blocks are definitely lost in loss record 16,847 of 16,875
at 0x4C2DADE: malloc (vg_replace_malloc.c:298)
by 0x4C2FC91: realloc (vg_replace_malloc.c:785)
by 0xA1F89FA: g_realloc (gmem.c:159)
by 0xA1BAD2E: g_array_maybe_expand (garray.c:779)
by 0xA1BA566: g_array_set_size (garray.c:555)
by 0xA1BBCB8: g_byte_array_set_size (garray.c:1752)
by 0x8D1CC48: g_file_load_contents (gfile.c:6766)
by 0x5FAE767: gtk_icon_info_load_symbolic_svg (gtkicontheme.c:4501)
by 0x5FAED4F: gtk_icon_info_load_symbolic_internal (gtkicontheme.c:4622)
by 0x5FAEEE8: gtk_icon_info_load_symbolic (gtkicontheme.c:4711)
by 0x5F00246: gtk_css_image_recolor_load (gtkcssimagerecolor.c:118)
by 0x5F003E4: gtk_css_image_recolor_compute (gtkcssimagerecolor.c:170)
https://bugzilla.gnome.org/show_bug.cgi?id=772215
Warn about the situation when we've found a resource or file path,
but gdk-pixbuf fails to give us a pixbuf. This generally means that
either pixbuf loaders are not found or the shared-mime database
is missing.
We were missing all of the status directories, and a few sizes.
This was causing us to not find image-missing on systems without
hicolor icon theme (this basically only happens on Windows).
https://bugzilla.gnome.org/show_bug.cgi?id=764378
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
When creating icon info objects for unthemed files, we don't
really have a nominal size, so we pass 0 to mean 'load at
original size'. However, this is not what was happening.
To make this possible, add variants of some pixbuf loading
functions that take a scale factor instead of a desired size,
and use those when we don't have a nominal size.
This is sometimes needed, and calling into actual icon theme
code just for it is confusing - the resulting icon does not
depend on the icon theme at all.
https://bugzilla.gnome.org/show_bug.cgi?id=760536
This borrows heavily from the CSS4 fonts draft's font-palette, currently
found at https://drafts.csswg.org/css-fonts-4/#font-palette-control
The palette is mainly meant to trigger invalidations when colors used for
symbolic icons change, to potentially allow extending supported colors
in symbolic icons and to recolor all colors of a symbolic icon, not just
the main one.
The syntax for the property goes like this:
Name: -gtk-icon-palette
Value: default | name <color> [ , name <color> ]*
Initial: default
Applies to: all elements with icons
Inherited: yes
Animatable: yes, each color animated separately
The property defines a list of named colors to be used when looking up
icons. If a name is not defined, the value of the current "color"
property is used. Which names are relevant depends on the icons in use.
Currently symbolic icons make use of the names "success", "warning" and
"error".
"default" is the current behavior of the GTK when coloring symbolic
icons and is equal to the string
success @success_color, warning @warning_color, error @error_color
Animation is crudely implemented by animating colors that are in both
palettes that are animated and otherwise keeping the color from the
palette that defined it. Note that this can cause a sharp cut at the
beginning or end of the animation when the color goes away and will
therefore be replaced with the color property.
You can see an example of animations at
http://gfycat.com/CautiousPeacefulIaerismetalmark
Using lookup_icon() and lookup_by_gicon() with a size multiplied by a
scaling factor is almost certainly going to get worse results than using
their for_scale() variants.
If the svg pixbuf loader is not available, we end up with criticals
from gtk_css_image_icon_theme_draw because gtk_icon_info_load_symbolic
returns NULL without setting an error.
Avoid this by propagating the load error.
When recoloring symbolic SVG, do not modify the original width and
height of the passed-in file; the function later will scale the image
through gdk_pixbuf_new_from_stream_at_scale(), but we should still
use the original size to create the proxy SVG, or the image will
possibly be doubly-resized or blurry.
https://bugzilla.gnome.org/show_bug.cgi?id=750605
In order to provide a constant mtime between OS build and deploy time,
while also maintaining a hardlink content-addressed model independent of
timestamps, ostree sets all mtimes to 0.
The icon cache code currently ignores directories with mtime 0, assuming
they don't exist.
Track directory existence in a more precise way.
https://bugzilla.gnome.org/show_bug.cgi?id=745052
When loading SVGs from ICON_THEME_DIR_UNTHEMED GtkIconInfos,
such as those created for a GLoadableIcon, the size of the pixbuf to
load is set as a product of icon_info->scale.
But a few lines above, icon_info->scale is set to -1 for
ICON_THEME_DIR_UNTHEMED GtkIconInfos, so we'll end up always passing a
negative size to the GdkPixbuf loader, which is interpreted as the
nominal size of the image file.
Instead load the SVG at the desired scaled size in that case.
This fixes blurry icon in the notification panel in gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=744991
When loading a GResource-backed GFileIcon into a GtkIconInfo we
currently fail to populate the is_resource private field.
Also, since is_svg is set by looking at the filename, and
g_file_get_path() returns NULL for a GResourceFile, is_svg was always
FALSE.
https://bugzilla.gnome.org/show_bug.cgi?id=744991
Add links from gtk_icon_theme_list_contexts() to
gtk_icon_theme_list_icons(), and from there to the Icon Theme
Specification and the Icon Naming Specification.
https://bugzilla.gnome.org/show_bug.cgi?id=461249
For symbolic icons, we prefer symbolics in inherited themes over
generic icons in the theme itself. So far this was implemented
by looking at icon_name[0] and looking that up in inherited themes
if it is symbolic. But with automatic rtl/ltr handling, the first
icon name will always have an -rtl or -ltr suffix, and an icon
with that suffix is not going to exist in most cases. To fix this,
look for shorter icon names too, as long as they are still symbolic.
https://bugzilla.gnome.org/show_bug.cgi?id=737000
If the foreground color has an alpha != 1 we used to just pass that into
the svg. This is useful to e.g. render an insensitive icon. However,
that is not an ideal model for symbolics. For instance, if the icon uses
overlapping areas when drawing, expecting these to be opaque then the
transparent color will result in a different alpha value for the overlapping
area. Also, non-foreground symbolic colors are still rendered opaque, and
the recoloring of pngs can't handle transparent colors.
So, instead we extract any alpha from the foreground, render using the
opaque colors and then apply the foreground alpha to the entire result.
This means we get an even transparency, even for other colors, and we
can apply alpha for the pngs too.
https://bugzilla.gnome.org/show_bug.cgi?id=734668
If an icon theme has a file called "foo-symbolic.symbolic.png" which
was converted from svg using gtk-encode-symbolic-svg we will read
it in an recolor, allowing symbolic icons without using librsvg.
https://bugzilla.gnome.org/show_bug.cgi?id=730450
The Adwaita icon theme ships spinners in a scalable directory
with MaxSize=32 and Scale=1. One way to make them scale up in
hi-dpi would be to add an @2 directory with MaxSize=32 and Scale=2,
but that directory would also be consulted in non hi-dpi situations
and give us an effective spinner max size of 64.
Instead, treat svg icons implicitly as hi-dpi, and scale them
up to MaxSize * 2 when in hi-dpi.
Slapping file:// in front of a path does not guarantee a working
uri (e.g. if you are on windows and the path looks like F:\\...).
Therefore, go back to using g_file_new_for_path if we don't have
to deal with a resource.
This makes it possible to look up icons in resources using
the icon theme api, and should be used as a replacement
for installing icons below $pkgdatadir/icons and adding
that location to the search path.
Make icon lookup from resources work without the extra hicolor
component in the path. It is redundant, since we always treat
builtin icons as part of hicolor anyway.
This functionality is only exercised by gnome-shell, currently.
Therefore, forgetting to copy a field here means an instant
gnome-shell crash :-(. More tests needed.
Recent changes made it a breaking mistake to install symbolic icons
of the wrong size into a theme directory, or into the legacy unthemed
icon location.
Since this change affects many apps, do the extra work to keep these
icons working, but emit warnings, in the hope that this will lead to
cleaning up the mess over time.
Reuse the scale information that we have from loading icons
normally, when loading a symbolic icon, so that we apply the
same size constraints.
This commit assumes that svgs have the nominal size of the
directory they are in, which will be true for all current
symbolic icons.
Previously, we were taking thresholds and min/max sizes into
account when choosing the best theme dir, but when it came
to loading the icon, we always scaled icons from scalable
directories all the way, ignoring the min/max size limits.
This commit changes things around so that we now load icons
in Threshold directories at their nominal size, and scale
icons in Scalable directories only up to the specified limits.
To override this and keep the previous behaviour of scaling
all the way to the desired size, use the GTK_ICON_THEME_FORCE_SIZE
flag.
Add /org/gtk/libgtk/icons as a resource path, and ensure
that we always parse an index.theme file for hicolor which
makes the builtin icons available as part of the hicolor theme.
We add a new API, gtk_icon_theme_add_resource_path, which
can be used to add resource path as a base location for
icon theme content, similar to gtk_icon_theme_append_search_path.
