The code is confusing the stylecontext=>node transition, so I'll remove
it.
WIth the recent introduction of the parent style cachen, I'm not sure
it's worth it at all. Some crude benchmarking suggests a slight speedup
when removing the cache.
So no guarantees about adding it back later.
- GtkCssWidgetNode
for style contexts owned by a widget
- GtkCssPathNode
for style contexts using a GtkWidgetPath
- GtkCssTransientNode
for nodes created with gtk_style_context_save()/restore()
The functionality of it is supposed to grow, so better put it in a
custom file early.
This is just a naive split so far, the next patches will split things
further.
This guarantees we only create 1 extra style cascade in total for hidpi
and not one per style context.
Style cascades are now nested like this:
GtkSettings root cascade (scale == 1)
|
+-- GtkSettings per scale cascade (for any scale, no custom providers)
|
+-- GtkStyleContext custom cascade (for any scale, custom providers)
This requires a bunch of care when changing cascade-related properties
inside GtkStyleContext, so that it ends up with a properly setup
cascade, but I think I got those cases right.
The only thing we don't do yet is reverting to a GtkSettings cascade
when the last custom provider is removed from a custom cascade.
Instead of asserting, just print a g_warning() and try to work around
the problem.
I hope that g_warning() isn't too spammy for people that are hit with
it.
Also clarify the docs that not restore()ing after a save() is a bad
idea.
https://bugzilla.gnome.org/show_bug.cgi?id=743101
When creating the query path, explicitly specify if it's for a root node
or for a child. Relying on gtk_style_context_is_saved() is unreliable
(for example when updating the cache).
This gets rid of a bunch of awkward transitions. It's not a perfect
solution to the problem of "should we transition from this state" but it
gets rid of the ugliest offenders.
If a gtk_style_context_invalidate() is called on a widget's style
context (which nobody should ever do, sheesh!) and we're animating, stop
the animations.
Fixes crashers in Nautilus.
We need to clear the cache manually on full revalidates because
_gtk_css_change_for_child() will clear the full revalidation flags.
And then gtk_style_context_update_cache() will not do the right thing
(which is to clear itself).
Because we can switch from animating to non-animating pretty much
anywhere, do the check for animations unconditionally instead of trying
to cram it into the correct if path (and failing).
We now cache the results of lookups on the parent GtkCssStyle. This
allows sharing styles between widgets (recursively). However, this
only works if the styles can't potentially depend on siblings -
neither directly via sibling selectors or via position pseudo-classes
like :first-child.
Unfortunately, Adwaita currently uses first-child a lot, and in
particular for labels, which are the most common widgets.
The big benefits of this change are both less CPU - due to not needing
to compute styles again - and less memory usage - due to sharing of
the styles between widgets. Here's some nonscientific numbers I
collected while pondering the usefulness of this patch:
glade glade widget
demo demo factory
runtime styles styles
Adwaita before 19.1s 5800 1150
Adwaita now 18.9s 3800 970
Adwaita hacked now 14.5s 3100 910
simple before 11.3s 5800 1150
simple now 10.8s 1300 590
Adwaita: Adwaita as provided by GTK
Adwaita hacked: Adwaita with the first/last-child for GtkLabel removed
simple: A 250 lines simple GTK theme I use for testing
before: This patch not applied
now: this patch applied
glade demo runtime: Starting glade opening a large file and closing it
glade demo styles: GtkCssStaticStyle objects after opening glade with
the large file as per inspector
widget factory styles: GtkCssStaticStyle objects after startup as per
inspector
Previously we looked at the save/restore state when determining the
parent. This is wrong in the case where we're updating the cache though.
So we now save the parent in the style info.
After the parent changes in commit
3a337156d1 we need to refresh the cached
styles after the current style. After all, they now depend on the base
style.
After 3a337156d1 style lookups still used
the parent context's style as the parent style, even though after a
gtk_style_context_save() the root style of the style context is the
proper parent.
Testcase attached.
Instead of keeping an animated style everywhere, we replace it with the
static style when nothing gets animated.
Apart from making the code cleaner, this gets rid of a bunch of animated
style values that do nothing but wrap a static style.
The only style that is animated is the style of the unsaved primary
node. So there's no need to create animated style objects for the other
ones.
There is a bunch of ugliness in the code currently. Further commits are
expected to fix them.
GtkCssStyle is the base class to be used for all types of styles that do
exist.
GtkCssAnimatedStyle is the only implementation so far, that is exactly a
copy/paste of the old GtkCssStyle code.
After b49c7c3421 we were no longer doing a
full revalidate after GTK_CSS_CHANGE_SOURCE changes.
This fixes spurious failures of widgets not properly updating when
changing the theme.
GtkStyleContext was not properly handling the style cascade when
setting a screen, causing the inspector global CSS to affect the
inspector window, even though the inspector is using a different
screen now.
... and make it the default. This takes over the meaning from "none" for
this property in that it draws the fallback builtin image.
"none" now literally means no image will be drawn.
When a getter function (like get_color()) is called and the passed in
state doesn't match the current state returned via get_state(), we used
to do a trick: We called save()/set_state() on the context before
getting the values.
Unfortunately, since 3a337156d1 this
has the unfortunate side effect that it also creates a child element.
This breaks various old codebases (spinbutton has been fixed in
998feeb2bc, Webkit is fixed in
https://bugs.webkit.org/show_bug.cgi?id=137803 ) unfortunately.
So instead, look up the values manually ensuring that no child element
is created but the correct state is used.
Keeping them is a bad idea now where the widget paths are actually
changed by a save(). And almost all of the time, state or style classes
will be changed anyway.
Looking them up again is just a hash table lookup anyway.
GtkCssNodeDeclaration is a new struct with copy-on-write semantics.
It encapsulated the properties used to define a node in the CSS tree.
The idea is to use it in various places for caching, in particular as
key in hash tables.
This is a change for how CSS is applied.
Previously, subelements (I'll take GtkEntry icons as an example) were
treated as having the same parent as the regular elements. So a selector
such as
.entry
would match an entry inside a window. But it'd also match the icon image
inside the entry. So CSS like
.entry { padding: 10px; }
would add 10px of padding to both the entry itself and to the icon image
inside the entry, so the icon would effective have 20px padding. To get
around that, one would have to unset it again like so:
.entry { padding: 10px; }
.entry.image { padding: unset; }
This is getting more and more of a problem as we make subelements
respect more properties that aren't inherited by default anyway, like
backgrounds and padding/margin/border.
This patch has one caveat though: It makes calling
gtk_style_context_save() the first time have an important side effect.
It's important to audit code to make sure it is only used for
subelements.
And last but not least, this patch is only useful if code unsets
parent's style classes that it doesn't want to apply any longer. Because
style classes are inherited by default (and I don't think we want to
change that), the example will still apply until the subelements no
longer contain the .entry style class.
- gtk_style_context_get_background_color()
- gtk_style_context_get_border_color()
Those functions shouldn't be used anymore, because they don't represent
anything from the CSS styling we support. The background color often
isn't used due to background images and there are actually 4 different
border colors (1 for each side) - if there isn't also a border image in
use.
This was introduced as a hackish way in 3.6 to make font updates
propagate properly. But since then, font handling has been changed and
this flag is no longer necessary.
gtk_style_context_invalidate_internal() will respect only the current
saved state of the style context, which is wrong when updating the scale.
In that case, the whole style context needs updating.
Now that widget paths are allowed to have a state, use that state when
querying style properties. This uses a fast path in gtkcssprovider.c and
that is great.
Don't take a state when constructing the CSS matcher. Instead, rely on
the newly introduced state in the widget path.
This way, the state can be queried not only on the first element, but on
all elements of the widget path.
Set the widget path state flags with the state flags of the style
context.
We do not update the state flags but replace the previous one because we
want to be able to have save()/restore() unset state flags.
When validating the style context, we are copying the animations
from one StyleValues instance to another, and cancel the old ones.
It turns out that sometimes the old and the new StyleValues are
the same, and in this case, we end up cancelling the animations
for good.
One case where breakage from this was observed is that the spinners
in gtk3-widget-factory stop spinning when you open and close a modal
dialog on page 2. This depends a bit on the window manager; the problem
can only be seen if opening the dialog causes a transition to backdrop.
Regions are done in a very non-css way. They don't fit the DOM in that
they don't integrate into the CSS tree and they have very weird matching
behavior in selectors.
So I'm deprecating them now. GtkNotebook and GtkTreeview will continue
to use them and as long as they do, we can't remove the code for it.
But once those are ported it might be safe to remove the code as it will
clean up lots of places in the code by quite a bit.
... from per style data to only existing once per style context. This is
technically an API break because it no longer allows getting different
style properties between save()/restore() pairs, but I don't think this
was ever intended to work that way, as the style property API was to be
used and is used via gtk_widget_get_style().
And it simplifies code a lot.
