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.
Also, in places where we're computing a new CssValue based on an
old one, make sure that if nothing changes we're returning a reference
to the old one, rather than creating a new identical instance.
At the toplevel we have _gtk_theming_engine_get, which lets us pass
in a property context with (atm) the size to get the property for.
Then there is a lot of plumbing to push this down into the lower
layers of the style property code until finally hitting
the property resolvers.
I need this because I will be adding a property resolver for win32
theme parts, and they render differently depending on the size
(i.e. they don't scale linearly). The idea is that the code
to get the background properties will pass in the final size
and we will resolve the theme part specification to that particular
size.
If the old non-context calls are used we just hardcode a size
of 100x100.
Move the private get_cursor_color method belongs to StyleContext. Change
the api so that retrieving both primary and secondary color is possible.
I left the method private for now, though it should probably be public
as all the other getters.
