Re: wip/css

[Benjamin Otte <otte gnome org>]

A quick update:

The branch is ready to be merged. It's just waiting on a review from
Lapo and Cosimo (who are still on holidays till Monday I think). They
also probably need to fix various issues in Adwaita that were exposed
by these refactorings.

In the mean time, GTK CSS also gained support for the CSS properties:
- all values of background-repeat
- the background shorthand
- the border shorthand
- border-{top,right,left,bottom}-style properties
- border-{top,right,left,bottom} shorthands

I'm currently looking into implementing 'dashed' and 'dotted' border
styles with the ultimate goal of implementing
outline-{width,style,color,offset} for focus rectangles, but merging
the branch will not block on this.

Oh yeah, and one change I will add when merging the branch is Riu's
renaming of 'window-unfocused' to 'backdrop' - it's not on the branch
because it _really_ breaks Adwaita. :)

Benjamin


On Tue, Jan 3, 2012 at 4:31 AM, Benjamin Otte <otte gnome org> wrote:
> Happy new year everyone
>
> I spent too much of the holidays redoing the CSS infrastructure yet
> again. The result can be seen in the wip/css branch, or for the lazy,
> by clicking on http://git.gnome.org/browse/gtk+/log/?h=wip/css
>
> I'm posting this here so that people can have a look at it and comment
> on it while I finish the last touches on it. The branch has somewhere
> betwen 100 and 150 commits, so I'll give an outline to what changed,
> if you want more details, feel free to ask.
>
> For users, developers and theme coders:
>
> 1) the "states bug" is gone
> Current GTK master prefers selectors according to the sum of their
> GtkStateFlags. So if you match a widget that is focussed and active (a
> depressed button), any selector with ':focus' will be preferred to any
> selector with ':active', even if it's 'GtkButton.button:active'. This
> lead to huge lists of selectors in Adwaita, such as:
> http://git.gnome.org/browse/gnome-themes-standard/tree/themes/Adwaita/gtk-3.0/gtk-widgets-backgrounds.css?h=3.3.3#n2
>
> 2) performance of CSS lookups was roughly doubled
> I introduced an internal GtkStyleProviderPrivate interface that is now
> used to do lookups when available. The new approach is still far from
> perfect, so we may see further improvements to the interface. But for
> now: yay for performance, this should make Glade at least a tiny bit
> faster.
>
> 3) inheritance is done correctly now
> Previously, GTK traversed the widget path when looking up inherited
> properties. That is wrong, it should look at the stuff the actual
> parent element uses. New API in gtk_style_context_get_parent() now
> gives us that stuff.
>
> 4) a lot more CSS is available
> We now get the initial values for style properties right. We also
> support the special values 'initial' and 'inherit' for all properties
> and implement them according to the CSS spec. In fact,
> http://dev.w3.org/csswg/css3-cascade guided a lot of the internal
> design.
> Also supported across the board are the color values 'currentColor'
> (making colors equal to the foreground color) and 'transparent'.
> 'transparent' is alos supported in symbolic colors; currentColor as a
> special value is not.
> Last but not least, images are now rendered according to
> http://dev.w3.org/csswg/css3-images/#sizing - more on that below.
>
> For GTK developers:
>
> 1) GtkStyleProperty is a real GObject now
> In fact, it's a real object tree now:
> GtkStyleProperty
> + GtkCssStyleProperty
> + + GtkCssCustomProperty
> + GtkCssShorthandProperty
> Apart from spliting that big file up into lots of smaller chunks,
> there is now a clean separation between 'real' properties and
> shorthands and the lookup code can use that.
> And last but not least, the code per property has been cleaned up
> quite a bit, so it should now be even easier than before to add new
> properties. And you know you want to implement more of them!
>
> 2) the whole set of functions for properties is now API-documented
> That deserves a point of its own. So now that code is even explained to you.
>
> 3) We have a separate stage for the computed value now
> Again, see http://dev.w3.org/csswg/css3-cascade for the value
> computation process. This is only used for resolving colors and
> 'initial'/'inherit', but once we support lengths properly, quite a bit
> more will go on there.
>
> 4) GtkCssImage
> What was previously just a cairo pattern is now a custom object with 3
> subclasses: URL, gradient and win32 theme part. It also implements the
> sizing ideas from http://dev.w3.org/csswg/css3-images/ and should make
> it easy to support more types in the future, such as OS X themes or
> the new gradient definitions from the document I just linked to.
>
> 5) bypassing the public API
> With using _gtk_*_peek_property() we can now directly access internal
> objects and are no longer bound by the types exposed in the public
> API. For those, _gtk_style_context_query() and
> _gtk_style_context_assign() do the potential extra step.
> Why is this great? Because we can now grab the GtkCssImage directly
> from the background-image property and give it the width and height
> that the win32 code needs to draw it correctly. And we don't need to
> pass context through the API anymore.
> We can also use it in the future to have percentages, doubles and
> whatnot on all the properties while still maintaining a public API
> that says G_TYPE_INT.
>
> Thanks to Lap, Cosimo, Paolo and Zeeshan for reviewing the code while
> I was writing it instead of playing with fireworks.
>
> Benjamin