wip/css



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]