With StBoxLayout using the Clutter layout manager, it will now respect
actors' expand/align properties. However for the change to be transparent,
we need to support the existing child meta properties as well. Do
this by simply translating them to the corresponding ClutterBoxChild
properties.
https://bugzilla.gnome.org/show_bug.cgi?id=703810
With the BoxLayout containers in St and Mx and the ClutterBoxLayout
manager, we now have three more or less diverged implementations of
the same layout policy.
While removing StBoxLayout entirely in favor of ClutterLayoutManager
would be the fashionable thing to do, there are obvious drawbacks:
- it is the only actor we have that implements the scrollable interface
- it conveniently exposes its spacing property in CSS
- last but not least, it is used all over the place
So do the next best thing and make our implementation use the
Clutter layout manager internally - that way, the change is
transparent to users, while we get to refer most of the tricky
bits to Clutter. win-win!
https://bugzilla.gnome.org/show_bug.cgi?id=703810
Commit cfecd063c9 changed the allocation logic to not allocate
scrollbars when the *_visible booleans are false. This breaks the
fade effect as well as the NEVER policy. We do not paint scrollbars
when they are not supposed to be visible, so not allocating them
and thus leaving them in a "needs allocation" state just causes problems.
I am not convinced that it solved any problem to begin with (we don't paint
them anyway).
As the previous condition has basically always been true, just do it
unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=705664
We don't set :visible on the scrollbars, but use booleans to track
if they are visible. Thus check the booleans instead of the actor's
properties when allocating the scrollbars.
https://bugzilla.gnome.org/show_bug.cgi?id=704265
Use ClutterActor.allocate_align_fill() so we don't have to do
this math ourselves. At the same time, clean up the RTL handling
so that it's easier to follow.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
When the St theme is changed, the StThemeContext unrefs all the theme
nodes cached in it's internal hash table, then emits a signal to
notify all theme nodes that the current theme has changed.
The problem is that the first StWidget to catch a theme changed signal
will trigger a "style-changed" signal catched by its children first.
So the theme changed signal can't be processed properly to cleanup
StThemeNodePaintState before recomputing the theme.
This patch adds a weak ref to the StThemeNode in the
StThemeNodePaintState to ensure paint states are properly cleaned up
when the associated StThemeNode is freed.
https://bugzilla.gnome.org/show_bug.cgi?id=703859
Commit 318283fc70 optimized box-shadow rendering by not recreating
shadow materials on every allocation change. Other handles cannot
be reused and are updated regularly, however the patch missed the
cached corner materials - while those can be reused, we still need
to ensure that the currently used paint state references them.
https://bugzilla.gnome.org/show_bug.cgi?id=703909
It is the job of layout containers to arrange their children; having
a hidden feature that *also* allows children to be positioned freely
outside the parent's allocation is just odd.
With the last user of the feature gone, kill it.
https://bugzilla.gnome.org/show_bug.cgi?id=703808
Currently the box-shadow is rendering is done like this :
The first time we want to render a node that requires a box-shadow, St
creates an cogl offscreen surface of the size of the allocation and
renders the box into this offscreen buffer using modulation on the
alpha channel, this buffer is then blurred according to the CSS
parameters.
The problem with this method is that every time an StWidget is
resized, its box-shadow offscreen buffer has to be resized and
therefore rendered and blurred.
This patches propose an optimization for this use case by rendering
the box-shadow only once but at a size that is independent of the
StWidget's size. Then every time we need to paint this box-shadow, we
just render this offscreen buffer using a 9-slices.
This method only works when the allocation of the widget is bigger
than the minimum shadow size on which we can apply a 9-slices, that is
given my the radius of the corners. If the allocation is smaller than
this minimum size, we then fallback to the fully render/blur the
shadow (like before this patch).
https://bugzilla.gnome.org/show_bug.cgi?id=689858
While it is obviously still an error to call get_theme_node() on a
widget that hasn't been added to the stage hierarchy yet, asserting
on it hasn't proven too successful in avoiding those errors - it's
likely the most frequent reason for crash reports. Just accept that
there'll always be code paths where we can hit this case and make
it non-fatal.
https://bugzilla.gnome.org/show_bug.cgi?id=610279
The shadows are currently rendered by painting the actor we want to
apply shadow on, in an offscreen buffer. The problem is that when this
actor has an allocation padding (ie allocation that isn't at 0x0
relatively to its parent), this padding is added within the offscreen
buffer and as a result the shadow rendering is truncated because the
offscreen buffer size is the size of the allocation box, not the
allocation box + padding.
This patch reposition the actor at 0x0 with rendering it by changing
the initial transformation matrix when rendering the actor offscreen.
https://bugzilla.gnome.org/show_bug.cgi?id=698301
This makes it much easier to implement correct popup-menu behavior
in the case of nested bins.
This fixes the context menu key in application search results when a
result has focus.
https://bugzilla.gnome.org/show_bug.cgi?id=699800
The comment clearly intended that for this to be the case, but a typo
prevented this from actually being done. This fixes the focused state
of the search field not working more than once.
https://bugzilla.gnome.org/show_bug.cgi?id=699799
In most cases, we'll transition between two states on hover / focus.
Instead of recalculating and repainting our resources on state change,
simply cache the last state when we transition.
https://bugzilla.gnome.org/show_bug.cgi?id=697274
The background image, background image shadow and border image are
allocation-indepedent, so we can keep these in the node. Given that these are
are likely cached in the StTextureCache, the slight increase in code complexity
may not be worth caching these textures and materials -- we might be better off
just computing when we need to paint.
https://bugzilla.gnome.org/show_bug.cgi?id=697274
This ensures that two widgets sharing the same theme node won't trample
on each other's prerendered materials if the actors are of different
sizes. This also tries to be very careful to share as much as possible
during a transition.
This has the side effect that if a widget changes state a bunch of times,
we won't cache every state. Since we expect that state changes are
infrequent and that most cases we'll be able to use the texture cache
to do most of the heavy lifting, this cost is much more insignificant
than rendering a number of different actors with the same theme node
and different sizes.
https://bugzilla.gnome.org/show_bug.cgi?id=697274
Since we now share theme nodes between, we shouldn't cache the paint state
across all nodes. As a first step towards putting this in the actor, split
out the state into another structure. Keep it in the theme node for now
so that we don't make too many changes in one commit.
It's possible that some of these pieces of drawing state could be shared
between theme nodes. For the sake of simplicity, assume that none of them
are shared or should be shared. A future commit could identify those that
could be shared and move them back into the theme node.
https://bugzilla.gnome.org/show_bug.cgi?id=697274
We want to put the paint state in the actor rather than in the theme
node, as having two actors with different sizes but the same theme node
is now much less efficient.
https://bugzilla.gnome.org/show_bug.cgi?id=697274
Similar to the existing generic getter methods, add lookup functions
for URL properties like the standard background-image/border-image
properties.
https://bugzilla.gnome.org/show_bug.cgi?id=693688
The changes from commit b4f5f1e461 and b394d184cc increased the
instructions required for the fade fragment shader. This is over the limit
for some hardware (like intel gen3), which causes the driver to fallback
to software rendering for the shader. The result is that painting a scrollview
that has a fade effect takes around 30 (!!) seconds.
So lets go back to the old effect for 3.8 until we find a solution.
https://bugzilla.gnome.org/show_bug.cgi?id=696404
Curently it is possible to copy the content of password entries,
and paste it elsewhere in clear text. This is undesirable, so
follow GTK+'s behavior and disable the cut/copy actions for
password entries.
https://bugzilla.gnome.org/show_bug.cgi?id=695104
Since commit b4f5f1e461, the effect is eased in at the scroll
view's edges so that it does not appear out of nowhere. However,
the linear easing used is not the best option, as now the effect
appears so late that content near the edges ends up just being
cut off rather than faded out.
So adjust the easing function to have the effect appear faster.
https://bugzilla.gnome.org/show_bug.cgi?id=694327
If enabled, scrollbars take away from the allocation given to the
view's content. This is usually preferrable to painting the bars on
top of the content, but there are exceptions, for instance when the
content needs to be centered with regard to the view as a whole.
Add a :overlay-scrollbars property to account for those cases.
https://bugzilla.gnome.org/show_bug.cgi?id=694261
We cannot reset the cursor at the next leave event, as that might
happen on a NULL stage and cause a BadWindow error, so do it on
unmap (which is guaranteed to happen before the stage is cleared).
https://bugzilla.gnome.org/show_bug.cgi?id=694057
While we were relying on gtk_icon_info_load_icon and friends being
thread-safe, there was no such guarantee, and recent caching that
was added to GTK+ made it non-threadsafe. To replace it, _async()
variants of the icon loading code were added that are thread-safe.
Use those instead of using our own worker threads.
https://bugzilla.gnome.org/show_bug.cgi?id=692845
Instead of using Clutter to add an event filter for X events it now
uses the GDK API. The Clutter API won't work if Clutter is not using
an X11-based backend such as if Mutter is directly running with the
KMS backend. This is a step towards making Mutter be its own display
server and a step towards being a Wayland compositor. In this case GDK
will still be using the X backend because it will connect to the
headless X server.
https://bugzilla.gnome.org/show_bug.cgi?id=693438
Before version 1.2 of GLSL it would not implicitly convert from int to
float which meant that if you compare a float variable with an integer
constant it will generate a compile error. In particular this means
that on GLES2 (which uses GLSL 1.0) the scroll view shader will not
compile on pedantic compilers, which includes Mesa. This patch just
changes it to use floating point constants.
https://bugzilla.gnome.org/show_bug.cgi?id=693339
Cogl sets this for us since commit 2701b93f159bf2d3387cedf2d06fe921ad5641f3.
Setting it twice is illegal and causes compile failures:
error C0204: version directive must be first statement and may not be repeated.
Clutter translates keyboard state internally, and clears the lock bits
from modifier state, so translating again results in the wrong keysym.
Given that Clutter already gives us a fine keysym, we don't need this.
https://bugzilla.gnome.org/show_bug.cgi?id=692586
As theme nodes keep a cache of matched properties, we need to make
sure to update it when the list of stylesheets changes. In particular
this fixes a regression from commit dc2ec0a8f9, which caused
extensions with stylesheets to crash the shell when re-enabled (for
instances when coming back from the lock screen).
https://bugzilla.gnome.org/show_bug.cgi?id=692994
StThemeNodes cache matched properties from stylesheets, so when the
list of custom stylesheets changes, the node may miss better matches
(when a stylesheet was added) or have pointers to invalid memory in
the list (when a stylesheet was removed).
In order to allow theme nodes to listen for stylesheet changes, add
an appropriate signal to StTheme.
https://bugzilla.gnome.org/show_bug.cgi?id=692994
According to css3-transition, transition-duration is expressed
as a time, that is, in seconds or milliseconds. Fix that by
recognizing numbers with units and implicitly converting to
milliseconds after parsing.
https://bugzilla.gnome.org/show_bug.cgi?id=681376
The code here before was added as dummy code to satisfy an error
in the missing switch, and wasn't ever tested due to the lack of XI2
in mutter. Use the same math as GtkRange does to calculate scroll bar
positions from raw XI2 deltas to allow for proper smooth scrolling.
https://bugzilla.gnome.org/show_bug.cgi?id=687573
realpath() does a series of lstat() on each path component to resolve
symbolic links, but we just want to get an absolute path, and we don't
really care if it is physical or not. Going through a GFile does the
canonicalization we need, and is a lot faster.
https://bugzilla.gnome.org/show_bug.cgi?id=687881
StWidget considers "same theme node" as an indication that the style
did not change, and skips emitting style-changed in that case. This
means that icon theme changes are not picked up by StIcon.
https://bugzilla.gnome.org/show_bug.cgi?id=689353
Decorations are fairly uncommon in gnome-shell, so it's
worthwhile to avoid effort creating empty attr lists. This
can also help prevent a relayout.
https://bugzilla.gnome.org/show_bug.cgi?id=689400
This was due to incorrect pixel clamping, which bounced the height
of the actor between values. Just remove pixel clamping, as Clutter
will correctly do it for us.
https://bugzilla.gnome.org/show_bug.cgi?id=689243
This doesn't (or shouldn't) change the visual appearance of the fade
effect, but does do all the testing math inside the shader, rather
than on the CPU. This will make fading the offset much easier in
the future.
https://bugzilla.gnome.org/show_bug.cgi?id=689249
GLSL 1.20 is a better language, and we'll rely on it in future updates.
This doesn't have any additional constraints, since GLSL 1.20 was
standardized before GLSL-supporting drivers came out.
https://bugzilla.gnome.org/show_bug.cgi?id=689249
Theme nodes are interned and shared with other widgets, so they cannot
be disposed, otherwise we blow useful resources, and in particular we
break the parent-child chain.
https://bugzilla.gnome.org/show_bug.cgi?id=689029
The AnimatedIcon does not have an API for controlling the animation but
relies on the :visible property changes to start and stop a timeout used
to update the frame.
This has the inconvenient of having a side effect when visible is set to
true multiple times, and is not really the API expected from such
component. Also, there is a race if it is displayed before the images
are loaded: there is no child yet and thus we get this._frame = NaN
which leads to a crash.
Switch to a play/stop API instead, and add a load event callback to the
TextureCache.load_slice_image to exactly know when we can start using
the images.
https://bugzilla.gnome.org/show_bug.cgi?id=687583
It appears to be somewhat common for st_widget_style_changed() to be
called when no style-relevant attributes have, in fact, changed. Now that
we cache theme nodes, we're likely to get the same theme node back from
the cache. If we do, we don't need to waste time asking whether its
geometry and painting are equal to itself: we can just note that nothing
really changed and get on with our lives.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687465
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
If you copy a theme node's paint state into itself, it should be an
inexpensive no-op. What actually happened was that we destroyed the
old paint state, re-initialized to blank, then copied the blank state
back into itself. In the process, we lost (for instance) the textures
for rounded corners.
Until I introduced the texture cache, this never actually happened,
because when st_widget_recompute_style() calls st_widget_get_theme_node(),
we'd always get a fresh theme node. Now, we get a theme node T back
from the cache, notice that paint_equal(T, T) is true, short-circuit
slightly by copying its drawing state into itself, and destroy drawing
state that we still needed.
I'm going to fix this in recompute_style() too, but as a general
principle, self-assignment ought to be harmless.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687465
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Because we calculate and cache CSS properties once per StThemeNode,
and only a certain set of attributes can affect the CSS properties,
it's advantageous for as many widgets as possible to share a single
StThemeNode. Similarly, if a widget changes state and then changes back
(e.g. gaining and losing the :hover pseudo-class), it should ideally
get its original StThemeNode back again when it returns to the old
state.
Here, I'm using the StThemeContext as the location for a cache.
StThemeNodes are currently never freed: this seems OK for Shell's usage
(a finite number of IDs, classes, pseudo-classes and types).
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687465
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
In my testing this cuts the longest time to dispatch(), when showing the
calendar menu for the first time, from 604 to 442 milliseconds,
while reducing additional_selector_matches_style() from 32% to 13% of
CPU time used.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687465
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Rather than using a complicated set of function calls across
library boundaries and our own scanning logic, use strtok(),
which glibc already provides, and is probably much more optimized.
https://bugzilla.gnome.org/show_bug.cgi?id=687465
Currently we miss changes to a file referenced in background-image
or border-image.
Connect to the StTextureCache::texture-file-changed signal to keep
up with file changes and update the drawing state if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=679268
For textures loaded from files, the cache might hide image changes
by keeping the data of a previous version around indefinitely. For
instance AccountsService will notify of avatar changes, but as new
image is copied over the old one, we will continue to use the old
image data.
Install a file monitor for each file resource we load and clear
the corresponding data from the cache on changes, emitting the
new StTextureCache::texture-file-changed signal.
https://bugzilla.gnome.org/show_bug.cgi?id=679268
ClutterText will only queue a relayout after font changes if it has
any contents other than the empty string. As a result, its height
request may change after the first character has been entered. To
avoid this visual glitch, force a relayout on actual font changes.
https://bugzilla.gnome.org/show_bug.cgi?id=685534
The actor's GtkIMContext is freed in dispose and reset in unrealize - as
ClutterActor's dispose will unrealize the actor if necessary, chaining
up to the parent after clearing the im context will result in warnings
if the actor is still realized, so chain up first.
https://bugzilla.gnome.org/show_bug.cgi?id=686016
For performance reasons, resources required to paint a widget are
aggressively cached; we know of at least one case where our caching
prevents updating the used background-image correctly, so add explicit
API to clear all associated cache data.
https://bugzilla.gnome.org/show_bug.cgi?id=679268
StThemeNode caches its resources aggressively to keep the required
work on paint to a minimum - right now, resources are only recreated
on allocation changes.
In order to update the background-image property correctly when the
underlying file changes, resources need to be recreated without a
size change, so add an explicit method for that.
https://bugzilla.gnome.org/show_bug.cgi?id=679268
The current API assumes that image data loaded from files remains
valid during the life time of the shell. This assumption is mostly
valid for image files we provide ourselves (with the exception being
designers working on those files), but not necessarily for "external"
files - provide API to explicitly remove cached data associated with
a URI for those cases.
https://bugzilla.gnome.org/show_bug.cgi?id=679268
Rather than unconditionally removing a focus root in remove_group(),
decrement a counter that add_group() increments, and only actually
remove a focus root when the counter drops to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=682243
When using an input method like IBus, the IM is expected to process
key events before anything else. Currently this doesn't always work
as expected, as the event filtering is done in the default handlers
of the key-press and key-release events, e.g. only after other
handlers have been run.
To allow the IM to filter events earlier, move the code to a
captured-event handler instead.
https://bugzilla.gnome.org/show_bug.cgi?id=658325
If an actors is not mapped (visible and all parents visible), then don't
allow navigating focus to it.
This fixes a regression in the keyboard navigation of the panel with
invisibile items.
https://bugzilla.gnome.org/show_bug.cgi?id=683529
st_texture_cache_load_from_raw() enforces a square ClutterTexture,
resulting in the texture being stretched if the passed in image
data has a different width:height ratio.
Add padding in those cases as we already do when loading from pixbufs.
https://bugzilla.gnome.org/show_bug.cgi?id=683483
Introduce a StShadowHelper to manage drop shadows from JS (which
cannot use Cogl directly), and use it in a new StWidget-derived
JS class to draw the arrow.
https://bugzilla.gnome.org/show_bug.cgi?id=682285
Reroute setting those properties to a GIcon. API users are expected
to create GIcon directly now.
The advantage is that from a StIcon you can now create a similar one
by accessing :gicon.
https://bugzilla.gnome.org/show_bug.cgi?id=682540
StScrollBar was intercepting motion events by using captured-event on
the stage, which required additional dirty tricks, which required
additional hacks. Simplify it by just using clutter_grab_pointer()
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=671001
Add support for the CSS "background-repeat" property. Currently, this
only supports on/off, rather than allowing tiling in each individual
dimension. It is supported for both the cogl and cairo rendering paths.
https://bugzilla.gnome.org/show_bug.cgi?id=680801
The :reactive property is used on StButton to like the :sensitive
property on GtkWidgets, that is, to indicate that the user is not
(yet) expected to click the button, and therefore should affect
styling too.
This allows to remove some code at the JS layer.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
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
