StDrawingArea uses the member variable needs_repaint to keep track
of whether it needs repainting. The variable is set to TRUE correctly,
e.g. on allocation or style changes - alas, it is never set to FALSE,
resulting in the area being repainted continuously.
https://bugzilla.gnome.org/show_bug.cgi?id=632197
Non-uniform border-radii are already supported when using a gradient
background, this patch adds support for solid colors as well.
The currently applied technique of using corner textures and filling
the remaining area with rectangles is extended, so that each corner is
padded with rectangles to the size of the largest corner.
Add border-radius.js to test cases, to test non-uniform border-radii
with both solid color and gradient backgrounds.
https://bugzilla.gnome.org/show_bug.cgi?id=631091
Icons can be loaded as St.Icon.SYMBOLIC, FULLCOLOR, APPLICATION or
DOCUMENT. The first will look for a symbolic equivalent, the second
looks for a full-color version (and does fallback, eg, from
"drive-harddisk-usb" to "drive-harddisk"). APPLICATION and DOCUMENT do
full-color icons without fallback (as specified by the icon spec).
And update various callers to use the right flags.
Based on a patch from Matt Novenstern.
https://bugzilla.gnome.org/show_bug.cgi?id=621311
Switch to using the layer combine constant rather than the material
primary color for representing the opacity of the material; this
avoids triggering a Cogl bug where changing the primary color corrupts
the layer state.
https://bugzilla.gnome.org/show_bug.cgi?id=629616
* Use --warn-all, --warn-error
* Fix various broken gtk-doc
* Drop unused shell_get_event_related
* For header defines, we currently require them to end in _H to be skipped
* Drop the no-longer-necessary fix-meta-rectangle.py hack
* Move to the convention of using -private.h for headers that are,
well, private.
* Add shell-wm-private.h
Move shadow helper functions from st-theme-node-drawing to st-private
to make them available to widgets which want to add shadows to internal
actors.
Also add a new helper function for creating the shadow material from a
ClutterActor.
https://bugzilla.gnome.org/show_bug.cgi?id=624384
Reorganize the existing code which parses the -st-shadow property
to allow parsing different shadow properties and add support for
the text-shadow property.
https://bugzilla.gnome.org/show_bug.cgi?id=624384
If a shadow property is inherited from a parent, multiple StThemeNodes
share a common StShadow. It would be possible to use st_shadow_copy()
for this purpose, but proper reference counting is nicer.
https://bugzilla.gnome.org/show_bug.cgi?id=624384
Add basic support for background-position, which only supports absolute
values.
Also don't require an unit to be specified for 0 (because the unit does not
really matter here 0 is 0 regardless of the unit).
https://bugzilla.gnome.org/show_bug.cgi?id=624375
Add st_theme_node_paint_equal() and use that to do two things:
1) Avoid animating transitions where nothing changes.
2) Copy cached painting state from the old theme node to the new
theme node.
https://bugzilla.gnome.org/show_bug.cgi?id=627083
Creating an FBO may be expensive, so we should avoid the operation
if possible. When transitioning between theme nodes, the widget's
opacity is used to paint to the offscreen textures which are blended
together - this means that the textures have to be recreated each time
the widget's opacity changes. It is much more effective to paint the
textures at full opacity and respect the widget's paint opacity when
blending the textures together.
https://bugzilla.gnome.org/show_bug.cgi?id=627085
The function has been upstreamed as clutter_actor_contains() - with
the switch to clutter-1.4 it is now available to the Shell, so it
is no longer necessary to keep a copy in-tree.
https://bugzilla.gnome.org/show_bug.cgi?id=626512
Add support for the CSS :first-child and :last-child properties to
StContainer, and thus to all containers in St and ShellGenericContainer.
The internal ordering of the container's children is used to determine
the child to which to attach the pseudo class, not the children's
positions. This means that containers where positions can differ from
the ordering (ShellGenericContainer / StGroup) may behave unexpectedly,
so some caution is required.
https://bugzilla.gnome.org/show_bug.cgi?id=625316
There's an assertion in calculate_gaussian_kernel() to avoid a division
by zero - due to an unnecessary cast from float to int this assertion
is triggered incorrectly for small (but non-zero) values, e.g. a blur
radius of 1px.
"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
This function reads a single image file which contains multiple
images internally.
The image file will be divided using @grid_width and @grid_height;
note that the dimensions of the image loaded from @path
should be a multiple of the specified grid dimensions.
https://bugzilla.gnome.org/show_bug.cgi?id=598349
The framebuffer setup code can fail, e.g. when the texture used as
color buffer has a height/width of 0. In that case, the call to
cogl_pop_framebuffer() will crash the shell trigger an assert. Add
error checking to fail gracefully.
Add _st_actor_contains() in st-private for use within St, and
monkey-patch in a Clutter.Actor.contains() for use by javascript, and
then replace all the duplicate implementations with one or the other
of those.
https://bugzilla.gnome.org/show_bug.cgi?id=621197
Our behavior of reversing the animation when the widget's style
changes back to the previous one is sound. On the other hand, when
there's a change to a new style while a transition is active, we
simply cancel the ongoing transition. Updating the transition
correctly so that the new one starts from an intermediate state
is hard.
Nevertheless, if the style changes before any time of the transition
has elapsed, we should do better than the current behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=621140
The current code only sets up / updates transitions when the new
node's transition-duration is non-zero. It should cancel an
existing transition if the duration is 0.
It is sometimes desirable to fade smoothly between two styles
instead of changing it abruptly.
Add transitions controlled by the transition-duration CSS property.
https://bugzilla.gnome.org/show_bug.cgi?id=619025
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
When hovering over the entry's ClutterText, the entry itself
currently receives a leave event and updates the hover state.
Apply the same logic as StWidget itself to treat children as
part of the entry.
https://bugzilla.gnome.org/show_bug.cgi?id=620381
Currently shadows disregard the overall opacity, so e.g. setting
an ancestor's opacity does not effect the shadow. Fix this by
deferring the setting of the shadow's color until it is painted.
Also move duplicated drawing code from st_theme_node_paint() into
its own function.
https://bugzilla.gnome.org/show_bug.cgi?id=619083
Currently the size of an StGroup depends exclusively on the group's
children - it should be possible to override this behaviour with
fixed values in the CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=613907
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
