"text-align" allows setting the alignment of text, with respect to
other lines and allocated space, without requiring a reference to
the ClutterText (which is private for most widgets).
If not specified, all text is left-aligned.
https://bugzilla.gnome.org/show_bug.cgi?id=622447
It has probably crossed the line to evil by a mile or so, but here
it is: a Tweener.slowDownFactor replacement used by all animations
without exception.
While at it, update Tweener to use the new setTimeScale() upstream
function instead of adjusting the timeline directly.
https://bugzilla.gnome.org/show_bug.cgi?id=622249
StThemeNodes may have properties - namely shadows - which paint
outside an actor's allocation. This is not a problem unless drawing
is redirected to an offscreen buffer, in which case the actually
painted size is needed in advance when setting up the buffer.
Add a convenience method to calculate an allocation large enough to
paint the node.
https://bugzilla.gnome.org/show_bug.cgi?id=619025
Add st_theme_node_equal() - two nodes are considered equal iff they
refer to identical elements, so e.g. .example and .example:hover are
not equal, even if no .example:hover rule exists in the CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=619025
I have no idea why there existed code that if we saw e.g. min-width
without a width, we assigned min-width to ->width, thus effectively
treating it as a maximum.
Just delete that bit.
https://bugzilla.gnome.org/show_bug.cgi?id=618482
The (optional) spread radius allows to make the shadow bigger without
enlarging the blur value. Mozilla supports this parameter for the
-moz-box-shadow property.
https://bugzilla.gnome.org/show_bug.cgi?id=613832
StThemeNode holds a reference to its parent, but we never released
that reference. This could cause us to hold onto whole chains
of theme nodes with rather dire memory usage implications.
Also move the other g_object_unref into _dispose.
https://bugzilla.gnome.org/show_bug.cgi?id=614660
The idea behind this move is that we have a lot more control over
rendering if StWidget isn't a big pile of actors, and things are
more efficient.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
st_theme_node_adjust_preferred_width/height now limit the content area
of an actor to the max, if given. (The requested width/height may be
larger to make room for borders, etc.)
https://bugzilla.gnome.org/show_bug.cgi?id=606755
Some theme authors have stated interest in radial gradient backgrounds.
The w3c has some draft:
http://dev.w3.org/csswg/css3-images/#radial-gradients
As this is rather complex, we add only some very basic support, which
extends our syntax for linear gradients:
background-gradient-direction: [vertical|horizontal|radial]
Gradients are centered circles, whose size is determined by the closest
side.
https://bugzilla.gnome.org/show_bug.cgi?id=604945
Add support for a new -st-shadow property, which is based loosely
on the CSS3 box-shadow property:
http://www.css3.info/preview/box-shadow/
It defers from the specification as follows:
* no multiple shadows
* the optional color argument may be placed anywhere
* the shape is not determined by the widget's bounding box,
but by the background-image property
https://bugzilla.gnome.org/show_bug.cgi?id=603691
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
An earlier commit was overzealous in removing (out) annotations;
introspection supports (out) for integral types just fine, we
only need to remove them for (out) types where the caller needs
to allocate a boxed type.
https://bugzilla.gnome.org/show_bug.cgi?id=602131
If the space we're allocated is too small for our border + padding
constraints, don't give negative allocations to callers. Squash
to zero.
It isn't really useful for callers to get negative content sizes,
and certainly breaks most allocation code.
https://bugzilla.gnome.org/show_bug.cgi?id=600734
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
To work around a problem where libcroco < 0.6.2 can't handle
functions starting with 'r' or 'u', preconvert 'rgba' to 'RGBA'
when parsing stylesheets and then check for rgba()
case-insensitively.
(libcroco is uniformly case-sensitive, though the CSS spec requires
that ASCII should be handled case-insensitively.)
https://bugzilla.gnome.org/show_bug.cgi?id=597054
round() is a C99 addition, so causes portability problems:
different C library versions require different #defines to
enable it. So simply avoid using it.
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
