Most subclasses override get_preferred_width/height, but if they don't
(eg, StDrawingArea), then make sure they still take CSS-specified
sizes into account.
https://bugzilla.gnome.org/show_bug.cgi?id=614516
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
A pointer does not equal to an int on x86_64
(which results into pointer - pointer not being an int either),
fix that by casting the resulting value to an int.
Breakage was introduced by commit 909b5ec43c
If track-hover is set, update the hover property automatically, and
the "hover" pseudo class to match, as StClickable used to do. (Remove
the corresponding code in StClickable). Tweak the tooltip handling to
use track-hover, which also makes it slightly more reliable in the
presence of reactive children, etc.
Since style_class and pseudo_class are space-separated lists of names,
add new methods to add and remove individual names rather than just
re-setting the entire name.
Update existing code to use the new pseudo-class methods where
appropriate. In some cases, this may result in actors having multiple
pseudoclasses where previously they only had one at a time, but there
don't seem to be any visible differences.
(There are some places that could usefully use the new style_class
methods as well, but this patch doesn't change them.)
Also, update test-theme.c to test the new methods.
https://bugzilla.gnome.org/show_bug.cgi?id=604943
It's wrong to do anything that requires looking up a widget's style
before you add the widget to the stage, since its final style may
depend on properties inherited from its parents.
st_widget_get_theme_node() used to emit a warning in this case, but
many would-be contributors apparently didn't notice. Help them out.
https://bugzilla.gnome.org/show_bug.cgi?id=610279
StButton animated the background for button transitions; since these aren't
presently part of the shell design, simply remove them. We can readd
these in the future.
StTooltip should probably have :vertical and :horizontal pseudo classes
to make the arrow work but it should still function.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
Brute force merge these two by essentially replacing St.TextureCache
with a (renamed) Shell.TextureCache.
One function was added for convenience, namely "st_texture_cache_load_file_simple".
St.TextureCache had a function to load a texture from a filename, and it
returned NULL on error but only half the callers actually checked this. This
function is better.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
To comply with C89, structure initializers should have
only constant values.
(Not a thorough check for this throughout the codebase, just
StWidget is fixed up in this commit.)
https://bugzilla.gnome.org/show_bug.cgi?id=608746
By calling clutter_actor_get_allocation() in st_widget_recompute_style()
to determine whether to redraw gradients, we triggered a complete
reallocation of the stage for each gradient.
As gradients are processed in st_widget_real_style_changed() anyway, the
additional checks in st_widget_recompute_style() are redundant and can
be removed altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=608847
On style changes from gradient to solid backgrounds, the new background
must be drawn unconditionally, not depending on whether old and new
background color differ.
https://bugzilla.gnome.org/show_bug.cgi?id=608914
When moving a widget with a gradient, its allocation changes
continuously, resulting in constant redraws.
Checking for actual size changes before the operation avoids
unnecessary redraws.
https://bugzilla.gnome.org/show_bug.cgi?id=608715
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
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
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
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
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 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
ShellTheme replaces both StStyle and ccss_stylesheet_t.
The interface StStylable is replaced by usage of ShellThemeNode.
A concrete node class allows some significant optimizations of property
inheritance that would have been much more difficult to achieve with
the highly abstract pair of StStylable and ccss_node_t.
Some operations that were previously on StStylable (like the
::style-changed signal) are directly on NtkWidget.
Custom properties are no longer registered as param-specs; instead you
call directly into shell theme node to look up a length or color:
shell_theme_node_get_length (theme_node, "border-spacing", FALSE, &spacing);
The dependency on libccss is dropped, while preserving all existing
functionality and adding proper parsing and inheritance of font properties
and proper inheritance for the 'color' property.
Some more javascript tests for CSS functionality are added; workarounds for
a CSS bug where *.some-class was needed instead of .some-class are removed.
https://bugzilla.gnome.org/show_bug.cgi?id=595990
To each .c and .h file, add:
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
'gnu' is the default anyways for Emacs, but indent-tabs-mode is not,
so this sets things up to correspond to the policy of no-tabs.
http://bugzilla.moblin.org/show_bug.cgi?id=6467
Add GObject Introspection annotations to methods where needed, in
particular adding (transfer none) to return values that don't transfer
ownership.
st_texture_cache_get_actor() and st_texture_cache_get_texture()
are annotated as (transfer none) since they return a newly
created *floating* texture.
https://bugzilla.gnome.org/show_bug.cgi?id=591245
Import the core MxWidget/MxBin and their dependencies; we use the
namespace "St" (Shell Toolkit) because it is the same length as Mx
so enabling easy sharing of code, but makes it clear that this is
a friendly fork and not a literal import.
Based on a patch by Colin Walters <walters@verbum.org>
https://bugzilla.gnome.org/show_bug.cgi?id=591245
