Rather than having gradients be individually implemented by higher
level JS widgets, move basic gradient functionality into StWidget.
There is prior art in WebKit for CSS gradients:
http://webkit.org/blog/175/introducing-css-gradients/
However, implementing this would be quite a lot of work; all we
need in the Shell design at the moment is basic horizontal/vertical
linear gradients. So, the syntax now supported is:
background-gradient-type: [vertical|horizontal]
background-gradient-start: color;
background-gradient-end: color;
https://bugzilla.gnome.org/show_bug.cgi?id=602131
The behavior in respect to borders matches CSS - the properties set the size of
the content exclusive of the borders (CSS3 box-sizing property - not implemented
here - changes this).
min-width/min-height correspond very closely to the CSS meanings.
width/height are a little different from the CSS meanings - the CSS meaning is
"exactly this size unless overridden by min/max-width/height" - but within the
realm of our layout algorithm, making them control natural size is pretty
close.
This way we can force elements to have a fixed natural or minimum size.
https://bugzilla.gnome.org/show_bug.cgi?id=598651
The current CSS3 border-image is close to a superset of what we were
doing for -hippo-background-image. Woot! rename StThemeImage to
StBorderImage and change parsing to look for:
border-image: <url> <number>...
Rather than
-st-background-image: <url> <length>...
percentanges for the border sizes are not currently supported, neither
are the keywords for handling of the middle part. We always do 'stretch'
for now.
https://bugzilla.gnome.org/show_bug.cgi?id=595990
Rather than repeating the computation of borders in many different
widget subclasses, add helper functions:
st_theme_node_adjust_for_height()
st_theme_node_adjust_preferred_width()
st_theme_node_adjust_for_width()
st_theme_node_adjust_preferred_height()
st_theme_node_get_content_box()
That are used in get_preferred_width()/get_preferred_height() and
allocate() methods to consistently apply the necessary adjustments.
This allows removing the StPadding type.
Queueing a relayout when the borders/padding change is moved from
st_widget_real_style_changed() to the invoking code to allow access
to the old StThemeNode for comparison. (Should this be added as
a parameter to the signal?)
Borders are included in the geometry adjustments, but borders
are not yet drawn.
https://bugzilla.gnome.org/show_bug.cgi?id=595993
Add support for parsing and caching the border-radius property.
Different radii for the 4 corners are supported; elliptical corners
are not supported.
https://bugzilla.gnome.org/show_bug.cgi?id=595993
Add support for passing an inline-style string when creating a
StThemeNode.
Hook this up to a new 'style' property of StWidget.
Add a test case that demonstrates using this to update font sizes
on the fly.
https://bugzilla.gnome.org/show_bug.cgi?id=595991
Import:
HippoCanvasTheme => StTheme
HippoCanvasThemeImage => StThemeImage
HippoCanvasStyle => StThemeNode
StThemeContext is a new class managing the theme for a stage and
global properties like resolution.
test-theme.c is a newly written test program to do verification of the
style matching and property handling rules.
Various changes are made in the import:
- Comprehensive reindentation
- guint32 pixels replaced with ClutterColor
- General pseudo-class support added
- Old-fashioned (non-bordered) background image support added, though
with no support for repeat, etc.
- Bug fixes for problems revealed by test program
https://bugzilla.gnome.org/show_bug.cgi?id=595990
