clutter_actor_get_children returns a newly allocated GList and it was
not freed.
However, as there's no reason to copy the children list, switch to
iterator api.
https://bugzilla.gnome.org/show_bug.cgi?id=678406
Commit de8a66d4ce removed our own DPI handling for the one found
it Clutter, but broke resolution updates at runtime (for instance
when setting the "Large Text" option in Universal Access).
https://bugzilla.gnome.org/show_bug.cgi?id=677975
This swaps a use of GLfloat for a regular float. Cogl might stop
including a GL header in its public headers soon so this would fix a
compilation error.
https://bugzilla.gnome.org/show_bug.cgi?id=672711
Currently the scroll event code only handles scroll events if the
adjustment's value is within the "lower" and "upper" limits. The
likely intent was to pass events to a parent scroll view when
reaching the bounds (uh, nested scroll views!), but apparently
we never made use of this, as the upper bound is actually wrong
(an adjustment's maximum value is upper - page_size, not upper).
Just handle all scroll events unconditionally and rely on the
bound checks in StAdjustment.
https://bugzilla.gnome.org/show_bug.cgi?id=672413
Icon theme change signals aren't noticed immediately, they're usually
noticed when trying to load an icon. Since icon theme changes cause a
style change, and most icon widgets try to re-load their texture during
a style change, this means that we get a stack like this:
st_texture_cache_load_icon
gtk_icon_theme_lookup_icon
gtk_icon_theme_changed
st_widget_style_changed
st_texture_cache_load_icon
Rather than making every place that uses StTextureCache re-entrant,
punt the notifying of icon theme changes to an idle handler instead.
https://bugzilla.gnome.org/show_bug.cgi?id=673512
Currently compilation fails with -Werror, as we don't handle the
(newly introduced) smooth scroll events in switch statements; add
some basic support, which should make the compiler happy.
https://bugzilla.gnome.org/show_bug.cgi?id=672413
More than one outstanding request to the same URI should now be
deduplicated, and the framework is there if we want to cache async loaded
URIs as well
https://bugzilla.gnome.org/show_bug.cgi?id=672273
In the case that we don't have an icon corresponding to the gicon, it's
more than likely that the code calling load_gicon will know more about
what it wants as a fallback than the texture-cache itself. In fact -
we had a whole lot of dead code that would try to fall back, but never
did because we always returned a valid actor.
This was causing certain applications with invalid icons to not get the
fallback icon because an icon couldn't be found. Fix up the one place
where we don't have an explicit fallback icon codepath, and then stop
doing what we were doing.
https://bugzilla.gnome.org/show_bug.cgi?id=671656
This assignment was shadowed by the giant switch above. Since the
switch has a comment or two explaining the logic inside of it,
keep that instead of the assignment.
Since the invoker for navigate_focus has an extra parameter, annotations
from the invoker aren't applied on the vfunc itself. Fix that by annotating
the vfunc separately.
This allows us to do directional keyboard navigation when there's no
actor inside the horizontal or vertical strip extending from the
origin actor but there are other actors to the sides of that strip
that could still be used as targets even if that means the focus would
move diagonally.
https://bugzilla.gnome.org/show_bug.cgi?id=663901
For arrow keys navigation, when moving from a widget which isn't a
descendant of the widget we are going to, it's unexpected that focus
moves to the target's first descendant instead of the closest to the
source widget.
This requires us to use absolute coordinates to compare widgets since
we no longer have the guarantee that the widgets we are comparing are
siblings.
https://bugzilla.gnome.org/show_bug.cgi?id=663901
When porting from st_container_get_children_list to this code, I accidentally
broke StTable by a copy/paste error. This broke notifications that updated,
leaving them with what they think were 0 columns and 0 rows.
https://bugzilla.gnome.org/show_bug.cgi?id=670640
The very similar clutter_actor_allocate_align_fill is close enough
that this is just needless duplication. Additionally, allocate_fill
already inverts the align if the text direction is RTL, so we don't
need to do that here.
https://bugzilla.gnome.org/show_bug.cgi?id=670034
Now that StWidget is a group of sorts, it needs to account for its children
in its paint volume. Unfortunately, this causes havoc for StBoxLayout, so it
needs fixing - it's unknown why it worked when chaining up to near-identical
code in StContainer.
https://bugzilla.gnome.org/show_bug.cgi?id=670034
The get_focus_chain() implementation in StWidget just returns all
children, it should filter for visible children instead. This
breaks keyboard navigation in various places since commit 72dad591
removed the correct implementation in StContainer.
https://bugzilla.gnome.org/show_bug.cgi?id=670904
Now that ClutterActor has a ClutterContainer implementation, we
can start removing StContainer. To help make this a bit more
understandable, instead of converting everything at once, make
StContainer a compatible API wrapper around the ClutterActor
implementation, and then we'll remove those wrappers in later
commits.
https://bugzilla.gnome.org/show_bug.cgi?id=670034
Since an StWidget now has children, it needs to allocate those children
properly. Defer to the currently installed layout manager, like Clutter
does.
Now that we have something that allocates children in St, to prevent
double allocations, we use clutter_actor_set_allocation rather than
chaining up to StWidget::allocate.
https://bugzilla.gnome.org/show_bug.cgi?id=670034
Now that StWidget is concrete and instantiable, we need to do something
other than return an adjusted 0 for width and height. Just chain up
to ClutterActor's default implementation, which uses the layout manager.
https://bugzilla.gnome.org/show_bug.cgi?id=670034
Since we want to paint children by default in StWidget, we need to
provide a way for custom subclasses to paint their CSS backgrounds
without painting children... introducing st_widget_paint_background.
Additionally, remove any custom paint/pick handlers added by subclasses
of StWidget that just painted their children. This will cause double
painting if left alone.
This also removes the hacky things that some subclasses of StBin did
to prevent their one child to be painted by StBin.
https://bugzilla.gnome.org/show_bug.cgi?id=670034
Clutter now provides two new properties on ClutterActor - first-child
and last-child, so we have notifiers on when they change. Unfortunately,
it still doesn't help us too much - we need to keep track of the previous
values of the properties so we can remove their pseudoclasses.
https://bugzilla.gnome.org/show_bug.cgi?id=670034
We can't get rid of the implementations in StContainer just yet,
as StContainer still keeps its own child list. But this should
lower the amount of code that has to be moved around when we
remove StContainer.
https://bugzilla.gnome.org/show_bug.cgi?id=670034
clutter_container_foreach is deprecated, so let's replace that
with some ClutterActorIter usage. Additionally, remove the checks
for ClutterContainer, as all ClutterActors are now ClutterContainers.
https://bugzilla.gnome.org/show_bug.cgi?id=670034
The handle was a child of the trough, but it was allocated and painted
like it was a child of the bar. This will wreak havoc when we port over
to the new Clutter API, so let's just make it a child of the bar.
https://bugzilla.gnome.org/show_bug.cgi?id=670034
Clutter, since version 1.8, does The Right Thing™ inside the default
implementation of ClutterActor::map and ClutterActor::unmap, even for
non-container actors: it will iterate over the list of children and
map, or unmap, each one of them, respectively.
This means that the requirement to override map and unmap for composite
actors to map and unmap the internal children has been dropped.
https://bugzilla.gnome.org/show_bug.cgi?id=669239
Since our implementation of background-size is now CSS-compliant, we
do not need this subtexture hack that clips a "leak". The comment here
is also incorrect.
https://bugzilla.gnome.org/show_bug.cgi?id=633462
It seems that accidentally, two variables were swapped in one code path
of the background-size implementation, causing interesting but wrong
images for some elements.
https://bugzilla.gnome.org/show_bug.cgi?id=633462
A new texture has undefined contents - when we're creating a shadow,
we need to clear the contents of the texture before drawing the border
and background into it.
https://bugzilla.gnome.org/show_bug.cgi?id=668048
Implement the background-size CSS property, specified by the CSS
Backgrounds and Borders Module Level 3, including the keywords
"contain", "cover", and fixed-size backgrounds.
https://bugzilla.gnome.org/show_bug.cgi?id=633462
grid_width and grid_height were inverted, which caused a crash
in GdkPixbuf code. This was never noticed because the animation
in the panel is a square.
https://bugzilla.gnome.org/show_bug.cgi?id=666606
For some reason, the texture cache decides to make a request and then look up
an icon in the icon theme. If it's valid, it just returns, fine, but if it
doesn't add the icon, it tries to undo the request, leaking an
AsyncTextureLoadData that isn't freed in the process.
https://bugzilla.gnome.org/show_bug.cgi?id=660968
Rather than have five or six structs allocated duplicating data,
just keep one and simplify the code considerably.
Again, part of my ongoing quest to merge St and Mx.
https://bugzilla.gnome.org/show_bug.cgi?id=660968
If we add a 0-sized actor with a border-radius, we will crash as we try to
allocate a 0-sized texture in Cogl. Bail out early instead of doing that.
https://bugzilla.gnome.org/show_bug.cgi?id=661617
The translate coordinates are calculated as the offset after the scale, so it
needs to be applied after the scale as well. This fixes random centering issues
in the UI.
https://bugzilla.gnome.org/show_bug.cgi?id=660674
For GIcons we use g_icon_to_string() in the key, but the function
will return NULL if the icon cannot be serialized. As a result,
all non-serializable GIcons of the same size end up with the same
cache key - an example for this are contacts with avatars, which
currently all end up with the same image.
To fix, opt out of caching for GIcons which cannot be serialized.
https://bugzilla.gnome.org/show_bug.cgi?id=660585
Setting up the framebuffers for transitions may fail, in which case
the material used for drawing is left uninitialized, so trying to
access it results in a crash.
Instead bail out in this case, which means that we won't paint
anything during the transition - still, drawing errors are better
than crashes ...
https://bugzilla.gnome.org/show_bug.cgi?id=659676
Instead of doing complex computations in the shader just pass in the correct
fade area (taking padding, scrollbars and rtl into account) and just work
with that in the shader.
That fixes a bug where we would fade the scrollbar when padding is present.
https://bugzilla.gnome.org/show_bug.cgi?id=659159
StAdjustment has some non-functional and unused animation vestiges
like the "elastic" property, st_adjustment_interpolate() and
st_adjustment_clamp().
This commit vacuums that stuff up so it doesn't tempt anyone into
trying to use it.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
If a container is not clip-to-allocation, then its get_paint_volume()
needs to include the paint volumes of all of its children, since they
(or their children) may paint outside the container's allocation.
Also, if the superclass get_paint_volume() returns FALSE, then the
subclass should return FALSE too.
https://bugzilla.gnome.org/show_bug.cgi?id=655812
Clutter 1.7.x introduced CLUTTER_CAIRO_FORMAT_ARGB32: which can be used when
sharing textures/data with cairo without having to do check the
byte order and choose the appropriate format by hand.
https://bugzilla.gnome.org/show_bug.cgi?id=654577
The cogl path pads the corners out to the maximum corner radius to make the
math and painting logic easier. Unfortunately, when the radius exceeds the
actor's halfsize, the padding ends up interfering with other corners, creating
a big mess of rendering errors.
It'd be extremely complicated to fix this properly in the Cogl code,
so take the Cairo fallback.
https://bugzilla.gnome.org/show_bug.cgi?id=649513
Currently, any cases of overlapping corners were just ignored and rendered incorrectly.
Implement the corner overlap algorithm as specified by the W3C to fix this.
https://bugzilla.gnome.org/show_bug.cgi?id=649513
Only skip the areas of the scrollbars when they are invisible
and add take the horizontal scrollbar into account as well
when calculating the faded area.
https://bugzilla.gnome.org/show_bug.cgi?id=651866
Using the list of stylesheets loaded with st_theme_load_stylesheet(),
one can build an StTheme that is completely identical to the previous
one, except for one property (application-stylesheet).
This allows rt and the user-theme extension to work while respecting
the theming of other extensions.
https://bugzilla.gnome.org/show_bug.cgi?id=650971
Theme authors now have the power (and responsibility) of creating fade
effects with the new CSS length property '-st-fade-offset'. A value of
0 disables the effect.
This new CSS approach replaces the current programmatic toggle of
the 'vfade' property. A new CSS style class name 'vfade' is used as
a replacement for the old property.
https://bugzilla.gnome.org/show_bug.cgi?id=651813
Remove a workaround for clutter_actor_get_transformed_position() not
working inside paint(), and remove a comment about
ClutterText::position not being properly notified, since it is now.
(However, it doesn't seem worth it to rewrite the code to use
notification, since that would actually end up being more complicated
than the current solution.)
https://bugzilla.gnome.org/show_bug.cgi?id=648758
StScrollBar was tracking whether or not it currently had a valid
allocation, but since Clutter 1.4 there is a method it can call to get
that information instead.
https://bugzilla.gnome.org/show_bug.cgi?id=648758
==13810== 11,360 bytes in 1 blocks are definitely lost in loss record 18,574 of 18,765
==13810== at 0x4005447: calloc (vg_replace_malloc.c:467)
==13810== by 0x5191882: standard_calloc (gmem.c:107)
==13810== by 0x51920A7: g_malloc0 (gmem.c:196)
==13810== by 0x4056201: blur_pixels (st-private.c:466)
==13810== by 0x40573B4: _st_create_shadow_cairo_pattern (st-private.c:710)
==13810== by 0x4070746: st_theme_node_paint (st-theme-node-drawing.c:856)
==13810== by 0x3FEFFFFF: ???
https://bugzilla.gnome.org/show_bug.cgi?id=649497
This property represents that the widget is being labelled by an
actor. The name is label-actor to avoid problems with the current
StButton:label and StTooltip:label
If a caller sets an StLabel's text to what it already is (as, eg, the
clock menu does), do nothing. Unless the label is editable, in which
case, setting the text has a visible side effect (dropping the
selection), so we don't optimize that out.
https://bugzilla.gnome.org/show_bug.cgi?id=645648
If we're unmapped (or destroyed) during a scroll, we want to clean
up the changes we've made to Clutter's event handling, remove our
signal handler, and emit ::scroll-stop.
https://bugzilla.gnome.org/show_bug.cgi?id=646825
The next draft of the CSS Backgrounds and Borders module will actually
define when the blur radius means. Fix our code to use that definition
(2 * standard deviation) rather than using the 1.9 * that we extracted
from what Mozilla was doing.
https://bugzilla.gnome.org/show_bug.cgi?id=632506
Some functions in StTextureCache enforce square ClutterTextures,
even in cases where the underlying CoglTexture has a different
width:height ratio.
Add padding in those cases to keep the resulting image from being
stretched.
https://bugzilla.gnome.org/show_bug.cgi?id=643866
If, for example, the stage is divided into multiple monitors, we
might want to constrain tooltips so they don't cross monitor boundaries.
Add a function to set a per-stage callback to constrain tooltips.
https://bugzilla.gnome.org/show_bug.cgi?id=645547
Instead of showing tooltips immediately on hover, wait until a timeout
after the last motion (timeout is given by the gtk-tooltip-timeout
GtkSetting.)
https://bugzilla.gnome.org/show_bug.cgi?id=642871
Use ClutterContainer functions for adding the tooltip instead of
calling clutter_actor_set_parent behind the stage's back, and do
it inside st_widget_show_tooltip (which is a normal method) instead
of overriding st_tooltip_show, which is a vfunc and it is called
internally by Clutter, therefore it is limited in what it can safely
do.
Also, instead of positioning the tooltip with clutter_actor_set_position,
modify the anchor point when the associated widget moves, so that
only a redraw is queued.
https://bugzilla.gnome.org/show_bug.cgi?id=635100
Inside the Shell, all the UI (including chrome, the overview, and
the actual windows) is not a child of the stage but of a special
ClutterGroup, which is cloned inside the magnifier.
Add function for setting this special actor so that actors added by
St are visible in the magnifier. Nothing yet uses this, but the
tooltip will soon.
https://bugzilla.gnome.org/show_bug.cgi?id=635100
As of commit 34ce17c4b3, search results use large icons, or thumbnails
when available. To keep the amount of upscaling for the latter as small
as possible, request a large thumbnail size.
https://bugzilla.gnome.org/show_bug.cgi?id=645493
StButton was mistakenly considering any Space/Enter KEY_RELEASE to be
a click, when in fact it should only count as a click if it also got
the corresponding KEY_PRESS as well. This meant that when typing in a
chat notification, any Space/Enter keypress would dismiss the
notification, since the StEntry would take the PRESS event but ignore
the RELEASE, allowing it to propagate to the notification itself,
which would treat it as a click.
https://bugzilla.gnome.org/show_bug.cgi?id=645243
When we compare the boxes for two actors, they may appear to overlap
by a small amount because of floating-point imprecision. Allow for
up to 0.1 pixel overlap when determining what children are in the
focus direction from the currently focused actor.
https://bugzilla.gnome.org/show_bug.cgi?id=644134
clutter_init() fails under normal circumstances like
being unable to open a display connection, so it shouldn't
be handled with g_error() producing a core dump.
Clutter consistently produces an error message when
clutter_init() fails, so we don't need to print out any
error message.
https://bugzilla.gnome.org/show_bug.cgi?id=643910
The number instructions in a shader is limited to 64 on r300 hardware,
the fade shader in StScrollViewFade was ending up using 97 instructions
which is way over the limit.
So refactor the shader to use less instructions by precomputing as many
values as possible outside of the conditionals. The resulting shader
ends up using 34 instructions which is well within the hardware limits.
https://bugzilla.gnome.org/show_bug.cgi?id=644589
GThemedIcon expects the first name to be the most specific, and
will thus prefer it to later ones. We thus need to order the names
from the longer to the shorter.
https://bugzilla.gnome.org/show_bug.cgi?id=621707
When navigating from a non-immediate descendant of a container, we
were attempting to use clutter_actor_get_transformed_position() to get
the exact position of that actor relative to the container, but this
did not really make sense, since we would be using the position of
the intermediate container when navigating back.
https://bugzilla.gnome.org/show_bug.cgi?id=644134
g_themed_icon_new_with_default_fallbacks() does not do what we want
with symbolic icons; if the user's icon theme is not "gnome", then it
will end up preferring a non-symbolic icon from the higher-level theme
over a symbolic icon from gnome-icon-theme-symbolic.
If the shell requests a symbolic icon, and there is only a
non-symbolic icon available, that should be considered a programmer
error, just like requesting a non-existent icon name. So change the
code to only look up "-symbolic" names when drawing an
ST_ICON_SYMBOLIC icon.
https://bugzilla.gnome.org/show_bug.cgi?id=644142
Add Ctrl-Alt-Tab support to ViewTab, and fix the Applications pane to
scroll to track the keyboard focus.
The Windows pane can be switched to, but navigation within the pane is
not yet implemented.
https://bugzilla.gnome.org/show_bug.cgi?id=618887
PopupMenuManager was pretending that it knew nothing about the menu's
sourceActors, while also trying to handle keynav between them. This
was a big mess, and resulted in bugs in navigation between panel menus
and the Activities button, and it totally gets in the way when trying
to add keynav to the dash (whose menu sources are arranged vertically
rather than horizontally).
Fix this up by moving the panel-specific parts to PanelMenuButton
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=641253
At times, RTL locales require different CSS, so always create theme
nodes with :ltr/:rtl pseudo classes depending on the widget's text
direction, to provide an easy way to handle those cases without
requiring a separate stylesheet.
https://bugzilla.gnome.org/show_bug.cgi?id=643835
The vertical scrollbar is located on the left in RTL locales, so
pass an additional parameter to the shader which indicates the
locale's text direction.
https://bugzilla.gnome.org/show_bug.cgi?id=643156
In RTL locales, the vertical scrollbar should be located on the
left, so take the widget's text direction into account when
allocating the view's elements.
https://bugzilla.gnome.org/show_bug.cgi?id=643156
Currently an entry's primary/secondary icon can only be set by
filename. In order to allow using themed icons, add API to set
a generic ClutterActor as icon.
https://bugzilla.gnome.org/show_bug.cgi?id=642333
For historical reasons, StEntry always did hover tracking when you had
visible hint_text, even if track_hover was FALSE. Remove that special
case, and make entries track hover just like all other widgets do.
If we actually needed to distinguish hovered-with-hint-text from
hovered-without-hint-text (which, at the moment, we don't), we could
do that by setting separate CSS for :hover and :hover:indeterminate.
https://bugzilla.gnome.org/show_bug.cgi?id=642483
If we aren't going to fill the content area of the node with a solid
background color, then we need to clear it of any artifacts left over
from drawing the border.
https://bugzilla.gnome.org/show_bug.cgi?id=640465
This reverts commit b4ec342d06.
The alpha > 0 checks should actually be alpha < 255 for the commit to
make sense as designed. The design isn't right either, though,
since we need to preserve the translucency in translucent gradients,
not block it with a solid color fill.
https://bugzilla.gnome.org/show_bug.cgi?id=640465
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
Add st_texture_cache_load_icon_name_for_theme() which, when loading a
symbolic icon, gets a #StIconColors from the theme node and uses that
to colorize the icon.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
A new StIconColors object is used to efficiently track the colors
we need to colorize a symbolic icon.
st_theme_node_compute_icon_colors() is added to compute the
StIconColors for a theme node. (Refcounting of StIconColors means
that we'll typically share the colors object of the parent node.)
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Scaling up icons from the loaded size to a larger size is uniformly
ugly and results in a long series of "fuzzy icon" bugs. It's better
to just load at the specified size and center. (Centering can be
overridden by packing not-fill in the parent container.)
https://bugzilla.gnome.org/show_bug.cgi?id=633865
We don't want the layout to change when we say, change from
battery-full to battery-full-charging, so we should request a square
based on the icon size unconditionally and not try to adapt to the
size of the texture we loaded. This also means that our layout is
independent of the loaded texure which, if we switch away from
using a ClutterActor child will allow us not queue a relayout when
the icon finishes loading.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Make StIcon compile and work in St.
Changes:
* ::icon-type and st_icon_set_icon_type are added to allow
specifying SYMBOLIC/FULLCOLOR for an icon.
* Ability to set the icon name from the theme is removed; it
wouldn't easily fit into our framework and two levels of
abstraction between code and image doesn't seem that useful.
* size CSS property is renamed from x-st-icon-size to icon-size
to correspond to what we are doing elsewhere.
* CSS and property based icon sizing are cleanly layered - if
you set the icon-size property, the CSS size is ignored.
* Add a simple JS test of StIcon.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
StIconType will be used by a new StIcon class, so move it to the
header file of common enumerations. Including st-types.h which had
the St single-include check revealed that st-texture-cache.h didn't
have that check and several places were including that directly.
Fix that up.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
The ability to set a "content image" on an icon relies on the ability
to have custom theme properties of a "border image" (9-slice) type.
We don't have this, and the capability of a bordered image specified
by the theme can be achieved more naturally with standard CSS facilities.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
* Make sure all source files have a LGPL copyright header, and standardize
non-standard variations of the header to a common form.
* Check and update all copyright notices.
* Remove 'Written By:' lines. They are universally incomplete and
typically indicate only who started a particular file.
https://bugzilla.gnome.org/show_bug.cgi?id=634550
We weren't properly nulling out the vadjustment variable in dispose()
which meant in the case of explicit-destroy followed some time later
by garbage collection and disposing the actor again we would crash.
Use StWidget:track-hover rather than doing it ourselves. Don't assume
that hover is always TRUE after an enter_event or FALSE after a
leave_event, since we have a pointer grab and will be getting other
actors' events.
Don't ungrab the pointer when it leaves the button, since that
destroys the whole point of getting a grab in the first place.
Only consider the button to have been clicked when it has both grab
(meaning the mouse was pressed over the button) and hover (meaning the
mouse was released over the button).
Also remove the virtual pressed/released methods, which weren't being
used anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=633853
Add StWidget:can-focus, st_widget_navigate_focus(), and
st_container_get_focus_chain(), and implement as needed to allow
keyboard navigation of widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=621671
In d66e7dd49 I got confused between border_texture and
background_texture. The background_texture was being created as normal
but in the one place that it gets drawn I accidentally made it use the
border_material instead. This patch makes it create a
background_material similar to the border_material and uses it to
paint.
A few places in st-theme-node-drawing create one-shot material, paint
with it and then free it. This is suboptimal with current Cogl because
it will end up compiling an ARBfp program just for that single paint
and then it will throw it away when the material is destroyed.
There is a new function in st-private.c called
_st_create_texture_material. This creates a simple material for a
texture based on a common parent material that points to a dummy
texture. Any materials created with this function are likely to be
able to share the same program unless the material is further modified
to contain a different number of layers. It would be possible to use
cogl_set_source_texture for this instead except that it's not possible
to modify the material's color in that case so we couldn't render the
texture with opacity.
The corner textures are now stored as a handle to a material that
references the texture rather than storing the texure directly. There
is also a separate border_material member which always points to
border_texture as the only layer.
https://bugzilla.gnome.org/show_bug.cgi?id=633340
Although within St itself there are situations where the semantics of
these functions (return TRUE or FALSE and return the actual value in
an out parameter) is useful, it's mostly just annoying at the
application level, where you generally know that the CSS property is
going to specified, and there is no especially sane fallback if it's
not.
So rename the current methods to lookup_color, lookup_double, and
lookup_length, and add new get_color, get_double, and get_length
methods that don't take an "inherit" parameter, and return their
values directly. (Well, except for get_color, due to the lack of (out
caller-allocates) in gjs.)
And update the code to use either the old or new methods as appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=632590
st-theme stores some loaded stylesheets in a custom
stylesheets list. When removing items from this list
it unrefs them, but when adding items to the list it
neglects to ref them. This means that under certain
circumstances the list will contain items that have
already been freed.
https://bugzilla.gnome.org/show_bug.cgi?id=632477
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
