We need to store the border widths independant of them being set to 0 by
border styles, because otherwise we'd need to track that dependency and
recompute on changes, and I don't want to add more entries to
GtkCssDependencies just for this special case.
By moving the code that does the setting to 0 from the compute stage to
the query stage, we can achieve this.
Now we need to just be aware that the actual value stored is not set to
0 when we use gtk_css_computed_values_get_value().
Otherwise the evil widgets that don't chain up their map and unmap
vfuncs will not get updated style contexts. This is in particular true
for GtkWindow and the CSS Theming / animated backgrounds demo in
gtk-demo.
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 needed for the SELECTION_NONE mode where nothing is ever
selected, but its also needed for CTRL-<key> keynav that moves the
focus without changing the selection.
https://bugzilla.gnome.org/show_bug.cgi?id=684984
Currently the GdkWindow used for dragging is created once when
the first drag starts, and the reused identical each time.
Instead, just recreate it for each drag, with the correct size.
This reverts commit f2cb8f1270.
The patch actually didn't work for at least text. I currently have no
clue why, but I suspect it requires investigating Cairo code and
recording surfaces, and I'll not do that right now.
Split out the blurred shadow rendering in three steps:
- creation of a surface of the appropriate size - we use the clip
rectangle as a good measurement for the size, since we won't render
out of it anyway
- painting the unblurred shape on the surface - this is responsibility
of the single shadow implementations
- blur the surface and compose the result back on the original cairo_t
This means we can share code between the implementations for the first
and third steps; it also makes the code independent of the rendered
size, so we can avoid passing down a cairo_rectangle_t with e.g. the
icon coordinates.
The code accesses pixels in a chunks of 4 bytes, so we must only support
formats where the size of a single pixel is 4 bytes.
Fix RGB24 to be 4 bytes (the alpha channel is ignored) and disallow A8.
We were adding one child too much to the style context path when
generating it for the internal buttons, which in turn caused sibling
selectors from the theme such as :first-child to apply to both buttons
under certain circumstances. Spotted by Lapo Calamandrei.
As long as we don't have an API for explicitly inverting the bar, it
makes more sense for the progress in vertical orientation to fill from
the bottom.
