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
Rather than having ShellTextureCache know about the type of each
item it's caching, this lays the foundation for simply caching
arbitrary string -> CoglHandle.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
For StWidget we want the ability to load raw CoglHandle references
rather than having a big pile of actors backing StWidget.
Several bits of StWidget expect to be able to synchronously load
textures; this is a crutch to support that until we can cleanly
make this asynchronous.
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
StScrollBar: Be robust against being disposed multiple times,
which can happen, and in fact, normally happens when destroying
the parent.
StScrollView: Implement remove() for the hscroll and vscroll members,
and just destroy them in dispose() and let them be removed.
unparent the shadows, instead of just unref'ing them directly.
https://bugzilla.gnome.org/show_bug.cgi?id=611203
Add a 'vshadow' property to StScrollView, which, when turned on,
overlays gradient shadows on the top and bottom of the StScrollView.
Turn this on for the StScrollView used for the app browser.
https://bugzilla.gnome.org/show_bug.cgi?id=609604
The type we don't currently handle is _ALWAYS, my original use
of g_return_if_fail was wrong.
Also the default should be AUTOMATIC in the properties, not ALWAYS.
Finally the test case was still using the incorrect St.ScrollPolicy.
https://bugzilla.gnome.org/show_bug.cgi?id=609015
Previously we were hacking out the vertical scrollbar, this patch
allow us to sanely say in which directions we want to scroll.
Note this patch intentionally changes St to depend on GTK+ in the
API. I believe this is a correct long term change where we should
view St as co-evolving with GTK+ rather than replacing or paralleling.
https://bugzilla.gnome.org/show_bug.cgi?id=609015
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
In StBin, StBoxLayout, and StTable, if a child has a potential
allocation that is larger than its preferred size, we give it its
preferred size instead. However, the corresponding
get_preferred_height/width methods were not making the same
assumption, which meant that if we had more width than the widget
wanted, we would allocate it its preferred width, but with the height
that corresponded to the larger width.
Fix this by defining new helpers _st_actor_get_preferred_width() and
_st_actor_get_preferred_height() and using them everywhere. Also, make
StBin and StTable use _st_allocate_fill() rather than having
nearly-identical duplicate copies of the code.
https://bugzilla.gnome.org/show_bug.cgi?id=609848
The forward/backward steppers are always allocated a square region at the
scroll bar's ends. Change the allocation to be based on the steppers' size
requests instead.
https://bugzilla.gnome.org/show_bug.cgi?id=609401
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
StButton has an internal animation for the border-image actor, then
it connects to the "completed" signal passing itself as data. However,
if the button is destroyed, nothing prevents the animation's completed
signal from then causing a reference to freed memory.
Holding a reference to the button is the most straightforward fix here.
https://bugzilla.gnome.org/show_bug.cgi?id=607825
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
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
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
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
