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
