summaryrefslogtreecommitdiff
path: root/gtk/gtkcssinheritvalue.c
Commit message (Collapse)AuthorAgeFilesLines
* cssvalue: Remove GtkCssDependenciesBenjamin Otte2015-03-181-5/+2
| | | | They are not used anymore.
* css: Move scale to GtkStyleProviderPrivatewip/mir2Benjamin Otte2015-02-061-8/+6
| | | | | | This way, we can remove it as a separate argument from gtk_css_value_compute() and allow computation to only depend on one thing: the style provider.
* cssstyle: Rename GtkCssComputedValues => GtkCssStyleBenjamin Otte2015-01-071-3/+3
| | | | | This is literally just renaming of the object (and the associated source files). No other changes are in there.
* css: Implement "unset"Benjamin Otte2014-05-111-0/+6
| | | | | | | | | | | | | Quoting the spec: If the cascaded value of a property is the unset keyword, then if it is an inherited property, this is treated as inherit, and if it is not, this is treated as initial. Spec in question: http://dev.w3.org/csswg/css-cascade/ Also use unset in the reset-to-defaults.css we use to reset css in reftests.
* css: Add a scale argument to css-value compute vfuncAlexander Larsson2013-07-031-0/+2
| | | | | | | | We need to be able to compute different GtkCssImage values depending on the scale, and we need this at compute time so that we don't need to read any images other than the scale in used (to e.g. calculate the image size). GtkStyleProviderPrivate is shared for all style contexts, so its not right.
* cssvalue: Use _gtk_css_initial_value_get() for the inherit valueBenjamin Otte2012-11-251-2/+2
| | | | See previous commit(s).
* css: Huge refactoring to avoid computing wrong valuesBenjamin Otte2012-09-281-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* cssvalue: Pass property ID to transition functionBenjamin Otte2012-09-031-0/+1
| | | | | | | 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...
* cssvalue: First step of proper dependency trackingBenjamin Otte2012-08-281-7/+10
| | | | | Instead of using the EVERYTHING aka FIXME value for tdependencies, actually compute the dependencies in a bunch of simple cases.
* css: Introduce dependencies for value computationsBenjamin Otte2012-08-281-4/+8
| | | | | | | | | 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.
* css: Move computing of initial and inherit valuesBenjamin Otte2012-08-281-10/+11
| | | | | ... to the compute vfunc. Simplifies code quite a bit. But makes the code no longer a simple step-by-step implementation of the spec.
* css: Pass property_id to compute functionBenjamin Otte2012-08-281-0/+1
| | | | | | | | | | | | | | | | 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.
* css: Introduce _gtk_css_value_compute()Benjamin Otte2012-08-281-0/+9
| | | | | | | 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.
* cssvalue: Add _gtk_css_value_transition()Benjamin Otte2012-04-171-0/+9
| | | | | | | 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.
* cssvalue: Add _gtk_css_value_equal()Benjamin Otte2012-04-171-0/+8
| | | | | | | | | | | | | | | | 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...
* styleproperty: Make _gtk_style_property_parse_value() return a CssValueBenjamin Otte2012-04-171-0/+59
Also split out initial/inherit handling into a custom GtkCssValue class.