This property needs to be treated as flags, not as
enum, since it should be possible to specify more
than one value, e.g.
text-decoration-line: underline overline;
Tests included.
Fixes: #3621
Replace uses of gtk_css_style_get_value with direct access,
throughout the tree. We don't replace all uses, just those
where we are dealing with a fixed property. Be careful to
handle the currentColor special case for color properties.
When a css value has "child" css values (e.g. a linear gradient has
several color stop css values) which are all computed (won't change when
compute() is called on them), we want to skip computing the entire
subtree.
Since css values are immutable, we can set the is_computed flag at
construct time.
Since GtkCssValue instances are 0-initialized in _gtk_css_value_alloc,
the default for is_computed it FALSE. This commit only sets it to TRUE
in a few cases, such as various "none" singleton values which will never
change. Later commits will refine this and set it for more values.
This is just lots of renaming.
The interface remains private, so the public API does not change, apart
from removing the definition of the Interface object to avoid
subclassing.
__builtin_popcount is a GCCism that is used to count the number of bits
involved, which means any non GCC/CLang compilers won't like the code,
meaning that on MSVC builds we must implement it ourselves.
We first use __cpuid() to check whether the CPU supports the popcount
instruction, if it does, we use the __popcnt intrinsic, otherwise
(untested, since I don't have a system that does not have the
instruction), we use the suggested hacks at
http://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetParallelhttps://bugzilla.gnome.org/show_bug.cgi?id=773299
As Benjamin says, ident should only be used if any value
is valid, which is not the case here. So use enums instead,
which should also be more efficient. To handle the more
complicated cases like font-variant-ligatures, we have to
introduce flags-like values.
Drop the current css2-style font-variant property and
replace it with a shorthand as specified in the css3 fonts
module. Currently, we fully support the font-variant-ligatures,
font-variant-position, font-variant-caps, font-variant-numeric
and font-variant-east-asian subproperties. font-variant-alternatives
is only partially supported.
When the blend modes were ported to use gsk defines, some
dashes were accidentally turned into underscores. It also
turns out that we were expecting 'saturate' instead of
'saturation' as per the css spec. Fix that as well.
I thought I needed ot rearrange the ordering of the animation-direction
values for the parser, overlooking the fact that we already parse them
backwards to address this very problem.
Our property parser stops at the first match when looking for
enums, so we need to order our values so that we don't end up
with prefixes of longer names being found first.
I noticed this when the parser tried to interpret
background-blend-mode: color-burn; as "color, with junk at the end".
It also affects animation-direction, which is also fixed here.
CSS supports blend modes, in which a series of layers are
merged together according to the given operation or set of
operations.
Support for blend modes landed on Cairo, which exposes all
the commons and also the exquisites blend modes available.
Adding support for blend modes, then, is just a matter of
using the available Cairo operations.
This patch adds the background-blend-mode CSS enum property,
and adapts the background rendering code to blend the backgrounds
using the available blend modes when they're set.
https://bugzilla.gnome.org/show_bug.cgi?id=768305
Fixes a couple bugs...
- Pixel font sizes in css would render as point sizes.
- For em font sizes, where the parent size was set and not default, we would
incorrectly convert a pixel value from points to pixels.
We'll always grab the default font size in pixels so we don't keep confusing
things.
Worth noting that gtk css font-size will still behave differently than the
web. Pango interprets font-size differently.
Clang complains that this check can never be true. Since this
is a argument range check which we do to catch bad input,
convince clang to not complain instead of taking it out.
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.
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.
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.
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...
