When we found an icon with exactly the requested size, we'd stop
searching immediately (good), but we'd neglect to set the returned
min_difference to 0 (bad). This caused theme_lookup_icon() to
prefer other, potentially much worse, matches over the exact one.
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.
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.
