This is the first step in replacing StyleContext usage with CssNode
usage.

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.

- Add docs explaining that it doesn't work everywhere
- g_warn_if_fail() in the APIs where it doesn't work

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.

We were already looking at the error anyway, but rewriting things
this way lets coverity see the light.

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

Fix warnings due to -Wdeclaration-after-statement and -Wshadow.

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

These icons are out there in the wild, and the warning causes
distcheck to fail. So, reduce it to a debug message.

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

Mention the name of the theme when an icon lookup fails.
https://bugzilla.gnome.org/show_bug.cgi?id=687963

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

Using 'highcolor' here seems confusing, since there is a theme
by that name. Just say full-color.

This can happen sometimes with GFileIcons that are
not representable as a local path. Better not to crash
in this case.

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.

This is a followup for 5a252f13

https://bugzilla.gnome.org/show_bug.cgi?id=733189

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.

We're using this name in two places, so match what we are doing
for the default theme name, and use a macro.

We use DEFAULT_THEME_NAME in gtksettings.c as well, and this
can be a confusing when grepping, so rename this to
FALLBACK_ICON_THEME.

Fix based on a patch by Stefano Faccini,
https://bugzilla.gnome.org/show_bug.cgi?id=732894

Builtin icons are deprecated in favor of loading icons
from resource paths.

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.

This makes it pretty straightforward to add individual icons
that don't need to be present in multiple sizes.

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.

We want to treat icons coming from resources as builtins that
are looked at as part of Hicolor.

We're always passing FALSE for scale_only, so why bother.

This is closer to what we were doing in the past.

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.

It sucks when printing a warning causes gnome-shell to crash,
so be more careful about icon names being NULL here.

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.

We no longer need a separate field for symbolic icon size,
now that we are using the directory size.

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.

This makes the GtkIconInfo struct a bit smaller.