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
Some changes to the way we handle CSS gradients:
* draw without padding, thus interpreting gradients as part of the
background rather than as content
* clip to (rounded) border area
* draw the border along the gradient instead of trying to align the
gradient layer with the background/border layer
* use the border_image actor instead of the background_image one
https://bugzilla.gnome.org/show_bug.cgi?id=606257
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
Move CSS handling of StLabel and StButton for their underlying
ClutterText objects into st_private, and implement support for
the underline and strikethrough St text-decoration properties.
Overline isn't implemented for lack of a corresponding Pango
attribute, and blink, well...
https://bugzilla.gnome.org/show_bug.cgi?id=599661
Now a StBin, and add hover/active style properties. Also, add the
event to the CLICKED signal. Otherwise a straightforward namespace
transformation.
https://bugzilla.gnome.org/show_bug.cgi?id=602131
It's nicer to have ShellDrawingArea as a St widget so it can
participate more cleanly in CSS styling, such as queuing a redraw
automatically on style changes, and allowing subclasses to use
CSS styling.
https://bugzilla.gnome.org/show_bug.cgi?id=602131
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
In a variety of places we're using boxes as data-modeling displays,
and in doing so we often want to either remove the children or
explictly destroy them.
Now ideally Gjs would support callbacks, and this would make using
the for_each functions possible, but even then these functions
are more efficient and shorter to type, at least.
https://bugzilla.gnome.org/show_bug.cgi?id=600734
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
StTheme CSS supports different border widths for different sides. Implement
it for StWidget by drawing the border internally. However, we don't support
a nonzero corner-radius with nonuniform borders.
https://bugzilla.gnome.org/show_bug.cgi?id=599442
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
ClutterGroup calls _destroy, but most of St was just calling _unparent.
This caused problems because the DESTROY signal was not emitted
for child elements after destroying a toplevel. Also, in a GC'd
binding it would cause unpredictable lifetime of children.
Some St widgets simply didn't have _dispose at all; implement it.
Note because of the usage of the background_image in StButton,
we can't cleanly destroy it inside the StWidget.
https://bugzilla.gnome.org/show_bug.cgi?id=597845
Add StIMText, which is a drop-in replacement for ClutterIMText but
uses GtkIMContext instead of ClutterIMContext.
StIMText doesn't have preedit support (would need ClutterText
changes), so isn't going to be useful for complicated input methods,
but is good enough to get dead keys and similar working.
entry.js: Simple test case of StEntry
gnome-shell.modules: Remove clutter-imcontext module
https://bugzilla.gnome.org/show_bug.cgi?id=597471
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.
Property enumeration names should correspond exactly to the property names;
in particular the ACTIVE vs :checked disparity was confusing reading the
code.
http://bugzilla.moblin.org/show_bug.cgi?id=6504
Convert the StTable code from StStylable to StThemeNode. The
:row-spacing and :col-spacing GObject properties are converted
into spacing-rows and spacing-columns style properties.
A new interactive test is added for StTable.
https://bugzilla.gnome.org/show_bug.cgi?id=596811
Remove the StTable specific methods to add actors:
st_table_add_actor()
st_table_add_actor_with_properties()
Since they shadow the generic ClutterContainer add_actor() method,
and patch in our add() convenience function as we do for
StBoxLayout.
https://bugzilla.gnome.org/show_bug.cgi?id=596811
Remove the StBoxLayout:spacing GObject property, and instead make
BoxLayout look up the spacing from the CSS style. This makes it
consistent with padding and will allow the use of units. (The
removal of the GObject property entirely instead of making it an
override is consistent with how we handle color, font, padding, etc.)
https://bugzilla.gnome.org/show_bug.cgi?id=596803
Add clutter-text properties to allow getting access to the underlying
ClutterText actor. This corresponds to the get_clutter_text() methods.
The PROP_LABEL and PROP_ENTRY enum values are renamed to PROP_TEXT to
match the names of the properties that they correspond to, and the
properties of StEntry are reordered into alphabetical order.
Based on a patch from Colin Walters
https://bugzilla.gnome.org/show_bug.cgi?id=591245http://bugzilla.moblin.org/show_bug.cgi?id=6313
StBoxLayout: Make consistent that the area scrolled and clipped
to is the content area (excluding borders and padding.) Translate
back appropriately when chaining up so that the parent background
is drawn at the right place and picking on the box (if it's reactive)
picks at the right place on the screen.
clip-to-allocation is removed from StScrollView since it's just
not right - if the child has any non-moving elements, like headers or
borders, it will need to set a narrower clip. And even if the entire
child scrolls, we want to clip to an arrow that excludes the scrollbars.
https://bugzilla.gnome.org/show_bug.cgi?id=595997
When a StBoxLayout is allocated a size less than its natural size,
think "shrink" needs to be divided among the children that have
a smaller minimum size than natural size.
This is done by preferentially shrinking the children that are most
expanded from their minimum size and then increasing that set of
children until we've found enough total shrink.
A new method is used of allocating children at integral sizes - instead
of rounding the per-child extra amount to an integer (which causes
cumulative round-off errors), compute the position as we go along in
floats and round individually for each child widget.
Extend the box-layout test to include of a test of a box being set
to various widths, starting quite narrow.
http://bugzilla.moblin.org/show_bug.cgi?id=6311https://bugzilla.gnome.org/show_bug.cgi?id=595995
If the actor isn't in a stage, then setting up the adjustment
based on the actor's size (which we can't compute) and the
size of the default stage (which isn't relevant), doesn't make
sense. Just use arbitrary default values.
The adjustments will be updated to reasonable values when first
the box is first allocated.
It's not entirely clear to me why we ever want to compute the
adjustment settings this way; perhaps we should always use
default values.
http://bugzilla.moblin.org/show_bug.cgi?id=6307https://bugzilla.gnome.org/show_bug.cgi?id=595996
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
Use BigRectangle to draw the border and background if there's
a border width or border radius and no border image. (Only
uniform borders are supported for now with some deviations
from the CSS model noted in the comments.)
The background color and image parameters are removed from
StWidget's draw_background() method since they were not used
for StButton (the only current user) and the encapsulation
break that they presented caused some minor problems.
Add a test case for borders, and also use borders to style
the buttons in the 'inline-style' test case.
https://bugzilla.gnome.org/show_bug.cgi?id=595993
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
