Now that we're using St.Icon in the Javascript, there is no reason
to have separate st_texture_cache_load_icon_name() and
st_texture_cache_load_icon_name_for_theme(), instead just add
the StThemeNode argument to st_texture_cache_load_icon_name().
https://bugzilla.gnome.org/show_bug.cgi?id=633866
Use st_texture_cache_load_icon_name_for_theme() so that we get the
right colors for symbolic icons. The code refactoring to achieve this
also avoids constantly starting a new icon load each time we set
a property on initialization ... the icon is loaded only after we
have a #StThemeNode assigned.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Scaling up icons from the loaded size to a larger size is uniformly
ugly and results in a long series of "fuzzy icon" bugs. It's better
to just load at the specified size and center. (Centering can be
overridden by packing not-fill in the parent container.)
https://bugzilla.gnome.org/show_bug.cgi?id=633865
We don't want the layout to change when we say, change from
battery-full to battery-full-charging, so we should request a square
based on the icon size unconditionally and not try to adapt to the
size of the texture we loaded. This also means that our layout is
independent of the loaded texure which, if we switch away from
using a ClutterActor child will allow us not queue a relayout when
the icon finishes loading.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Make StIcon compile and work in St.
Changes:
* ::icon-type and st_icon_set_icon_type are added to allow
specifying SYMBOLIC/FULLCOLOR for an icon.
* Ability to set the icon name from the theme is removed; it
wouldn't easily fit into our framework and two levels of
abstraction between code and image doesn't seem that useful.
* size CSS property is renamed from x-st-icon-size to icon-size
to correspond to what we are doing elsewhere.
* CSS and property based icon sizing are cleanly layered - if
you set the icon-size property, the CSS size is ignored.
* Add a simple JS test of StIcon.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
The ability to set a "content image" on an icon relies on the ability
to have custom theme properties of a "border image" (9-slice) type.
We don't have this, and the capability of a bordered image specified
by the theme can be achieved more naturally with standard CSS facilities.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
