Shorthand properties are basically the same a in CSS. For storage in
style properties or the CSS provider, they are unpacked into the real
values, so it is possible to partially override them.
No properties are yet converted to the new world yet, this is just the
code for supporting them.
... instead of duplicating code. This causes an extra g_value_copy().
If that turns out to be a performance issue, we can invent something
that handles this (like passing a gboolean take_value).
The reason for this duplication deletion is that we want to complicate
the setting code to handle shorthands by unpacking them and storing the
separate values.
Instead of initing the default style properties in the class_init
func of the style properties, init them when they are first needed -
when they are queried or when new ones are registered.
That way, they will always be available.
This will be used as a base both for parsing text-shadow and box-shadow
properties. The type is private, as there's no real use in exporting
this in a public API.
https://bugzilla.gnome.org/show_bug.cgi?id=649314
This has mostly two advantages:
- the most obvious one is the theme can render a border around the
sidebar if it wants to.
- we also can avoid hardcoding a container border width for the sidebar,
and just use a padding from the theme. This also allows different
themes to define a different padding, etc.
The drawback is we must draw the background ourselves, but it's easy
enough.
https://bugzilla.gnome.org/show_bug.cgi?id=650530
Lots of code calls gtk_menu_popup() and we don't want to resize the
window needlessly.
In this particular case, keyboard navigation to submenus caused those
submenus to shrink.
Note: I'm not sure this fix doesn't have nasty side effects, as I'm not
a specialist on menu popup code, so if it does, we'll need to revert it.
Until then, let's keep it, it fixes a bug.
If props == NULL in gtk_symbolic_color_resolve(), fail sanely for named
colors. The docs used to say it was not allowed to pass NULL for named
color, but that had problems:
1) You do not know if a color was created that way. This is especially
hard for generic users (like language bindings).
2) It wasn't even true. Colors using other symbolic colors would also
fail when trying to resolve their named colors, but the docs didn't
say so.
And because I want to use the function to resolve static colors early
where possible, I changed things.
This provides a huge speedup as we only need to preprocess style
properties when they are indeed inherited. This roughly doubles the
performance of the CSS matcher and brings the time taken by
gtk_css_provider_get_style() from 19% to 7% in my favorite benchmark.
One for the style properties, one for the widget style properties.
This way we can make one hash table by pspec which means we don't have
to repeat the pspec lookup.
Keep rulesets as an on-stack/heap structure instead of allocating all
instances separately.
Also, pass a ruleset to the ruleset parser, so we can make the ruleset
parser do lots of fancy things that might be useful for performance.
The code used the quarked name before, but when we already have the
pspec we want to have a lookup that does not involve quarking. And
lookup is equally fast if we only have the name.
