The recent change to the enum declaration for GtkCssChange actually
relied on compiler-dependent behavior, which also breaks the build on
some non-GCC compilers, such as Visual Studio. As noted in the
G_STATIC_ASSERT line just beneath this declaration, we need to change
this enum declaration to #define's, in order to fix the build in such
situations.
https://bugzilla.gnome.org/show_bug.cgi?id=752814
Properties like transition-property might change when hovering over
something, even if the property itself does not change. These properties
don't affect drawing, so don't queue redraws for them.
Previously, the (1<<31) value evaluated to the 64bit value
0xFFFFFFFF80000000
instead of
0x0000000080000000
Avoid this by explicitly casting the value to unsigned long long.
Also cast all values to unsigned long long to achieve consistency
and hopefully in the future get new values added the same way.
Instead of GTK_CSS_CHANGE_POSITION we now have 4 values:
GTK_CSS_CHANGE_FIRST_CHILD, GTK_CSS_CHANGE_LAST_CHILD,
GTK_CSS_CHANGE_NTH_CHILD and GTK_CSS_CHANGE_NTH_LAST_CHILD
Nobody is using them directly yet.
... and pass it to the API that computes new styles.
A special timestamp of 0 means "please don't animate" and is used when
no frame clock is available for a node.
The node declaration has the same functionality as
gtk_css_node_declaration_add_to_widget_path(). So instead of using that
function on a path, you can use the original path and the declaration in
a matcher.
So far the vfunc is kinda quirky (the path argument is an out argument
for something you have to free when you're done with the matcher), but
I'm about to change that.
This property is necessary to ensure widgets automatically update after
the text scale factor is changed desktop-wide.
And if I'm already doing a property like this, I can make it
overridable. So now you can override the dpi per-widget with CSS like
GtkSwitch {
-gtk-dpi: 48;
}
if you want to debug things.
Long-term, we want to get rid of this property and insist on dpi being
96 everywhere and people can change the font size to get larger fonts.
The property is useless to set (it only allows 'initial', 'inherit' and
'unset' as values), but it is used to track changes to the icon theme.
And as such, it can ensure that widgets can track when they need to
reload icons.
https://bugzilla.gnome.org/show_bug.cgi?id=743341
The order in which properties are defined depends on the order in which
they are computed. And that means that properties can only depend on
other properties that are defined before them.
The next patches will need this reordering.
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.
The values can be:
"requested" - the style as requested
"regular" - use a regular full-color icon
"symbolic" - use a symbolic icon
The property defaults to "requested", so no changes should be seen
unless CSS overrides it.
It is also inherited, so that using this CSS
.toolbar { -gtk-icon-style: symbolic; }
is enough to force the whole toolbar to use symbolic icons.
Rather than first collecting matches and then getting the change
for them we do the change collection directly on the tree. This
is about twice as fast.
We now support the keywords (like xx-small, medium, larger, smaller...)
and I've changed the default value to be "medium".
This required some shuffling of the "get default font size" code. But
all is well now.
GTK_CSS_DEPENDS_ON_EVERYTHING was used as a placeholder when
implementing dependencies. Now that dependencies are completely
implemented, it's no longer necessary.
When values are computed, they might depend on various other values and
we need to track this so we can update the values when those other
values change. This is the first step in making that happen.
This patch does not do any dependency tracking at all, instead it uses
GTK_CSS_DEPENDS_ON_EVERYTHING as a sort of FIXME.
The design principles were:
- synchronized
If multiple style contexts are animating, they should all do an
animation step at the same time.
- degrades well
Even when there's thousands of style contexts all animating at the same
time, the animation steps don't starve the CPU. This is achieved by
making sure the timeout is really fast. It just sets a bunch of flags.
- no hidden bottlenecks
Turning animatability on or off on a style context is O(1).
So far it is unused.
Deprecate public API where appropriate and make it no-ops.
Remove all calls to it.
Get rid of the 'transition' css property.
For now, this means spinners don't animate anymore.
