If a background gradient isn't fully opaque, then we need to first
fill in the background color so the border color doesn't leak into
the interior.
https://bugzilla.gnome.org/show_bug.cgi?id=640465
We need to be careful to ignore any preexisting color information
in the interior of the node when filling it with the background color,
since the border color may have leaked into the interior and the
background color may be translucent.
https://bugzilla.gnome.org/show_bug.cgi?id=640465
Point the arrow to the center of the sourceActor's content box, rather
than its allocation, in case it has asymmetric padding (as the
rightmost message tray summary item does).
https://bugzilla.gnome.org/show_bug.cgi?id=641728
For historical reasons, we had both StClickable and StButton, which
were nearly identical. StButton was more widely-used, so keep that and
port all StClickable users to that.
https://bugzilla.gnome.org/show_bug.cgi?id=640583
The material of prerendered backgrounds is now painted in the
rectangle determined by st_theme_node_get_paint_box(). As the
ClutterActorBox returned from that function includes the space
needed to draw the box shadow, the background ends up occluding
the shadow.
As the box shadow is not part of the background, factor out a new
helper function which excludes the box shadow, and use it to
prerender and place the background material.
https://bugzilla.gnome.org/show_bug.cgi?id=641522
1. Both functions leaked the nodes in priv->children
2. st_container_remove_all wasn't properly updating first_child and last_child
3. remove_all() is almost never right since it won't cause signal handlers
on the children to be removed. In the rare cases where it might be needed
the caller can simply use clutter_container_remove().
https://bugzilla.gnome.org/show_bug.cgi?id=640781
Previously, trying to use a background image and border on
the same node resulted in the background drawing over the border.
This commit adds support for background images to
st_theme_node_render_background_with_border
and changes the code to call that function when appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=636976
Loading a pixbuf in a way that cairo can use it is a
pretty involved process that involves a lot of code, and pixel
fiddling.
This commit adds the mechanism to StTextureCache so we can reuse
the existing pixbuf handling code there, and also get caching.
https://bugzilla.gnome.org/show_bug.cgi?id=636976
A lot of the border drawing logic in st_theme_node_render_gradient is
applicable to other non-solid background types than gradients.
This commit refactors that code so that support for other non-solid
background types can be more easily integrated later.
https://bugzilla.gnome.org/show_bug.cgi?id=636976
When drawing the background image shadow, we need to clip it
to the node's background color, gradient, or borders if present.
If the background color is transparent, and there aren't any
borders, then we don't clip the shadow since there is nothing
to confine it.
https://bugzilla.gnome.org/show_bug.cgi?id=636976
The border_texture (and border_material) variable is being
overloaded for two purposes: it's used as a source
to 9-slice the border from, and it's used as place to prerender
the background and border together for gradients.
While we only do one or the other for any given node, the two cases
are distinct, and should use distinct variables for readability.
https://bugzilla.gnome.org/show_bug.cgi?id=636976
Currently, "-st-shadow" can mean one of three very
different things:
1) shadow based on alpha of the background image
2) shadow the "border box" of the node
3) shadow applied to the content of a StIcon
It isn't well defined which of the above 3 cases
-st-shadow will mean for any given node, however.
This commit splits the property into three
different properties, "box-shadow",
"-st-background-image-shadow", and "icon-shadow"
to make it all very explicit.
https://bugzilla.gnome.org/show_bug.cgi?id=636976
StWidget reports a paint volume large enough to paint the current
theme node. As CSS transitions also paint the previous theme node,
the reported paint volume may be incorrect, resulting in screen
artifacts when painting outside the reported volume.
Add st_theme_node_transition_get_paint_box() to calculate an allocation
large enough to paint both theme nodes, and use it to report the correct
paint volume during transitions.
https://bugzilla.gnome.org/show_bug.cgi?id=640085
Right now is just redefine atk_object_get_name.
If someone wonders why not implement AtkText interface, or expose the
internal ClutterText, here a extract from AtkText doc:
"AtkText should be implemented by AtkObjects on behalf of widgets that
have text content which is either attributed or otherwise
non-trivial. AtkObjects whose text content is simple, unattributed,
and very brief may expose that content via atk_object_get_name
instead;"
StLabel is attributed, but is still simple and brief. In the same way
the atk_object_get_name redefinition is required, so this patch is the
first step. We can implement AtkText in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=626658
It includes:
* Expose a proper focusable state, instead of the default one from
cally, using StWidget::can_focus, and also notifying the state change
* Management of the selected stated, using the current pseudo_class.
* Defines a new virtual method on StWidget: get_accessible_type. In
this way it is not required to reimplement get_accessible just for
a accessible type change. get_accessible is reimplemented using this.
You can see that as a substitute of the atk object factory
https://bugzilla.gnome.org/show_bug.cgi?id=636716
Instead of converting a CSS-specified length to an integer by truncation,
round. This means that sizes specified by converting a pixel value into
non-px terms will work reliably instead of potentially being off-by-one.
We weren't freeing the whole pixbuf, nor were we the GList of
subpixbufs. Plug both of these leaks in the error handling path
and in the default case.
All of the unreffing/cleanup should happen in the GDestroyNotify
for the result, not some in the handler.
https://bugzilla.gnome.org/show_bug.cgi?id=636489
While non-uniform border widths were parsed correctly, an arbitrary
side's width was picked when painting, so that each border ended up
with the same width and the widths specified in CSS were ignored.
At least for sides between non-rounded corners, using a different
border width can be reasonable, for instance at screen edges.
Different border widths around rounded corners are kind of crack,
but then it would be lame not to support it ...
https://bugzilla.gnome.org/show_bug.cgi?id=607500
For gradient backgrounds, borders were implemented by filling the
background shape with the border color first, and then scaling down
the path to draw the background.
The result is not correct[0], which is especially visible if the border
width is greater than the border radius - so instead of scaling down
the original path, use a separate path for the background.
The result is consistent with the borders we draw for non-gradient
backgrounds, and much closer to the correct standard behavior.
[0] http://www.w3.org/TR/css3-background/#the-border-radiushttps://bugzilla.gnome.org/show_bug.cgi?id=607500
non-absolute paths specified as url()'s in
stylesheets are resolved to be relative to the location
of the stylesheets they are in.
Inline styles don't have physical styleshseets sitting on disk,
which leads to a crash in the url resolving code.
This commit ensures that we don't try to use the stylesheet associated
with a url, if there isn't one to use.
This commit doesn't try to handle relative paths in inline styles.
It only prevents crashes when absolute paths are used.
https://bugzilla.gnome.org/show_bug.cgi?id=636975
When scrolled, st_box_layout_apply_transform() includes the scroll
offset and affects paint volumes. This is right for our children, but
our paint volume is determined by our allocation and borders and
doesn't scroll, so we need to reverse-compensate, the same as we do
when painting.
https://bugzilla.gnome.org/show_bug.cgi?id=630932
In order to take advantage of clipped redraws (only redraw the
parts that actually changed), we have to inform clutter about
our paint_volume by implementing the get_paint_volume virtual
method.
As this feature had been added in in clutter 1.5.x we now require
that.
https://bugzilla.gnome.org/show_bug.cgi?id=630932
Aggressive compiler flags can cause the compiler to be smart enough
to inline functions and detect variables not being set on certain
code paths but not smart enough to understand the overall logic;
add some extra initializations to suppress the warnings.
Fix several minor bugs in the logic found when double checking the
logic before adding the initializations.
Based on a patch by Marc-Antoine Perennou <Marc-Antoine@Perennou.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=634225
Add a "gicon" property so that a GIcon can be used instead of an
icon name, while still getting icon recoloring from the theme.
Also include a compatibility wrapper in libshell until GJS has
support for interface static methods.
https://bugzilla.gnome.org/show_bug.cgi?id=622451
Connect to the "changed" signal on the default icon theme, and
when it triggers:
- Evict all cached looked up icons from the StTextureCache
- Fake a style change on all StThemeContext; this will result
in StIcon looking up icons again.
https://bugzilla.gnome.org/show_bug.cgi?id=633866
It is not referencing them when adding, and also it is connecting
to the "destroy" signal, emitted on dispose, so there is no risk
of storing finalized objects.
https://bugzilla.gnome.org/show_bug.cgi?id=634781
We were always drawing the border and background of each
StThemeNode, even if they were transparent. The simple
optimization of checking the alpha provides a significant
performance boost (in a quick test, it increased the
overviewFpsSubsequent metric in the core performance test
from 28fps to 35fps).
https://bugzilla.gnome.org/show_bug.cgi?id=634752
Now that we're using St.Icon in the Javascript, there is no reason
to have separate st_texture_cache_load_icon_name() and
st_texture_cache_load_icon_name_for_theme(), instead just add
the StThemeNode argument to st_texture_cache_load_icon_name().
https://bugzilla.gnome.org/show_bug.cgi?id=633866
Use st_texture_cache_load_icon_name_for_theme() so that we get the
right colors for symbolic icons. The code refactoring to achieve this
also avoids constantly starting a new icon load each time we set
a property on initialization ... the icon is loaded only after we
have a #StThemeNode assigned.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Sometimes it's useful to get the theme node if there is one and do
nothing and wait for the ::style-changed signal if there is no theme
node. Add st_widget_peek_theme_node() that just gets the current
theme node if available. The caller must handle a %NULL return.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
