Note: custom CSS properties still use the default GtkCssValue and always
will.
So there is a difference in css values used between those, even though
they both carry a GdkRGBA payload.
We now store the symbolic colors as a GtkCssValue which means that
we can reuse the color when resolving and storing the color in
the computed values in the style context.
Additionally we keep a last_resolved GtkCssValue cache in the
GtkSymbolicColor, and if resolving the color returns the same as
last time we reuse the old value. This further increases sharing
of Css Values.
If props == NULL in gtk_symbolic_color_resolve(), fail sanely for named
colors. The docs used to say it was not allowed to pass NULL for named
color, but that had problems:
1) You do not know if a color was created that way. This is especially
hard for generic users (like language bindings).
2) It wasn't even true. Colors using other symbolic colors would also
fail when trying to resolve their named colors, but the docs didn't
say so.
And because I want to use the function to resolve static colors early
where possible, I changed things.
The css parser has been modified to parse correctly radial gradients:
background-image: -gtk-gradient (radial,
center center, 0,
center center, 0.8,
from (#000), to (#fff));
The theming engine has been modified to correctly animate these,
as well as transitions between different pattern types.
This type defines a gradient between 2 symbolic colors, with any number
of color stop between these. At the moment it has been put besides
GtkSymbolicColor, although should be completely private, it will likely
need extending in the future for radial gradients.
At some point, it maybe should also be used for images, so painting
both a gradient and an image is consistent.
