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.
