| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
These are internal apis, and any external issues should have been
caught by checks at public API points. We use the internal checks
here because these checks show up in a non-neglible way on profiles.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here's the shortest description of the bug I can come up with:
When computing values, we have 3 kinds of dependencies:
(1) other properties ("currentColor" or em values)
(2) inherited properties ("inherit")
(3) generic things from the theme (@keyframes or @define-color)
Previously, we passed the GtkStyleContext as an argument, because it
provided these 3 things using:
(1) _gtk_style_context_peek_property()
(2) _gtk_style_context_peek_property(gtk_style_context_get_parent())
(3) context->priv->cascade
However, this makes it impossible to lookup values other than the ones
accessible via _gtk_style_context_peek_property(). And this is exactly
what we are doing in gtk_style_context_update_cache(). So when the cache
updates encountered case (1), they were looking up the values from the
wrong style data.
So this large patch essentially does nothing but replace the
context argument in all compute functions with new arguments for the 3
cases above:
(1) values
(2) parent_values
(3) provider
We apparently have a lot of computing code.
|
| |
|
|
|
|
|
|
|
| |
This is to allow animating arrays properly. I'm not really thrilled
about this solution (we leak propertys into the values again...), but
it's the best I can come up with - I prefer it to having N different
array types...
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Both _gtk_css_style_property_print_value() and
_gtk_css_style_property_compute_value() aren't necessary anymore and are
replaced by _gtk_css_value_print() and _gtk_css_value_comptue()
respectively.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a reorganization of how value computing should be done.
Previously the GtkCssStyleProperty.compute vfunc was supposed to take
care of special cases when it needed those for computation. However,
this proved to be very complicated in cases where values were nested and
only the last value (of a common type) needed to be special cased.
A common example for this was the fallback handling for unresolvable
colors.
Now, we pass the property's ID along with all compute functions so we
can do the special casing where it's necessary.
Note that no actual changes happen in this commit. This will happen in
follow-ups.
|
|
|
|
|
|
|
| |
This commit is essentially a large reorganization. Instead of all value
subtypes having their own compute function, there is the general
_gtk_css_value_compute() function that then calls a vfunc on the
subtype.
|
|
|
|
|
|
|
| |
... and Make this new value be a real GValue, as we don't need to save
performance for these anymore (it's just used for custom properties).
And I'd rather have code work for all values then be optimized for no
reason.
|
|
|
|
| |
.. and parse border-image-slice with it.
|
| |
|
|
|
|
|
|
| |
In particular, that's background-repeat and border-image-repeat.
Also, fix up the border-image shorthand to allow any order.
|
| |
|
| |
|
|
|
|
| |
... and convert those properties to this value.
|
|
|
|
|
| |
This is a tiny wrapper around _gtk_css_value_print().
It's intended for usage in gdb and printf debugging.
|
|
|
|
|
|
|
| |
Returns a value that transitions between start and end or %NULL if the
values cannot be transitioned.
So far, all implementations but numbers and rgba return NULL.
|
|
|
|
|
|
| |
Just store the value as px for now.
The font-size property needs a complete makeover anyway.
|
| |
|
| |
|
|
|
|
| |
And fix the parser to conform to the CSS spec while at it.
|
|
|
|
|
|
|
| |
Note: custom CSS properties still use the default GtkCssValue and always
will.
So there is a difference in css values used between those, even though
they both carry a GdkRGBA payload.
|
| |
|
| |
|
| |
|
|
|
|
| |
Instead, make the caller create a GtkCssValue in advance.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For now, we return FALSE for all default css values, so this is not very
useful.
I also think of this as an optimization equal, not a guaranteed equal,
because we don't even have a notion of what "equal" means.
For example, for background-repeat, "repeat, repeat" and "repeat"
are functionally equivalent. But the cssvalue has no idea that it's used
for background-repeat.
As a more complicated example, "repeat, no-repeat" and "repeat" are
equal to what one sees as long as there's only one image listed
background-image-source. But once you start transition'ing to an image
with 2 sources, it's different...
|
|
|
|
| |
Also split out initial/inherit handling into a custom GtkCssValue class.
|
|
|
|
|
| |
Having two constructors from GValues complicates refactorings, so I'd
rather not have them.
|
| |
|
|
|
|
|
| |
Also, constify GtkCssValue getters, so we can pass a const GtkCssValue
to the print_func.
|
|
|
|
| |
Don't use real classes, just a vtable.
|
| |
|
| |
|
|
|
|
|
| |
This got lost in the CssValue transition, and apparently some people use
this.
|
| |
|
|
|
|
|
| |
Seems these types were used in the parser tests, so we need to
handle them.
|
|
|
|
|
|
| |
We now have complete coverage in the GtkCssValue API for type
handling, so drop the GValue from internal storage and just create
new ones when needed.
|
|
|
|
|
|
| |
These represents the majority of int values in use (thousands in use
in a simple app). There is no need to keep multiple instances of
these around.
|
|
|