The following CSS would infloop:
@define-color self @self
as it would infinitely lookup the color named "self" and try to resolve
it. This patch adds detection of such cycles to the resolve function by
keeping a list of currently resolving colors in the cycle_list variable.
... instead of taking the last one we find. This is necessary as
attached widgets (mostly menus) can be attached to an invisible widget,
but we still want to invalidate styles for them.
https://bugzilla.gnome.org/show_bug.cgi?id=695772
We only FORCE_INVALIDATE when something weird changes that the CSS
machinery can't detect. But now that our style_updated functions skip
recomputations when some properties don't change we want to make sure
these recomputations are still run. So we just claim all properties
changed.
http://bugzilla.gnome.org/show_bug.cgi?id=695482
Add an API to start or stop continually updating the frame clock.
This is a slight convenience for applcations and avoids the problem
of getting one more frame run after an animation stops, but the
primary motivation for this is because it looks like we might have
to use timeBeginPeriod()/timeEndPeriod() on Windows to get reasonably
accurate timing, and for that we'll need to know if there is an
animation running.
https://bugzilla.gnome.org/show_bug.cgi?id=693934
Add a very simple GtkWidget function for an "tick" callback, which
is connected to the ::update signal of GdkFrameClock.
Remove:
- GtkTimeline. The consensus is that it is too complex.
- GdkPaintClockTarget. In the rare cases where tick callbacks
aren't sufficient, it's possible to track the
paint clock with ::realize/::unrealize/::hierarchy-changed.
GtkTimeline is kept using ::update directly to allow using a GtkTimeline
with a paint clock but no widget.
Switch GtkStyleContext to using GdkFrameClock. To do this, add a new
UPDATE phase to GdkFrameClock.
Add a GdkFrameClockTarget interface with a single set_clock() method,
and use this to deal with the fact that GtkWidget only has a frame
clock when realized.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
It's a lot uglier now, but it shouldn't crash anymore.
We must update the font description for animations, but we can't free it
on query, because some paths call gtk_style_context_get_font() twice in
a row without stopping the use of the first call. So us just creating a
new font description all the time and unreffing the old one is not a
good idea. So we just mere the new one into the old one.
https://bugzilla.gnome.org/show_bug.cgi?id=691186
This function is just a sophisitcated optimization.
If we know the GDK window's background will be opaque, we mark it as
opaque. This is so GDK can do all the optimizations it does for opaque
windows and be fast.
This is mainly used when scrolling.
The previous code didn't get this right, in particular it didn't enforce
a transparent background when it knew the background was not opaque.
This is for a very simple reason: The getter is returning a const value
and the font isn't const anymore. So we need to store the font
description somewhere but we can't reuse it as it's changing all the
time (yay animations, yay inherited values). Sucks.
So keep the hack in here but deprecate the function.
This is necessary because values in a GtkCssComputedValues can change
now. So if the font-size is inherited or animated, the cached value will
be outdated.
Fixes the fontchooser preview not updating.
Symbolic colors are an implementation detail of the CSS engine and have
been superceded by GtkCssColorValue. We don't want them clobbering the
public API. In particular because the only use I could find in the
public API is people using it to shade colors.
Make _gtk_style_provider_private_get_color() return a GtkCssValue (a
GtkCssColorValue to be exact) instead of GtkSymbolicColor.
With this, the symbolic color usage inside GTK is minimized.
If lookup->missing is empty we don't need to continue looking.
We short circuit in several places as this can happen
after iteratively makeign lookup->missing smaller.
Old code tried to use the "background-image" proeprty for setting the
default image background. While this used to work in the early days of
GTK3, today it is grossly misleading as the backgronud image may be
resized, repositioned and semi-translucent which causes very weird
artifacts when rendering.
So we use the background-color only instead.
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.
While regular animations should always be created, transitions should
not. This patch allows to express this by passing NULL as the values to
transition from.
It also adds a gtk_style_context_should_create_transitions() function
that returns TRUE when transitions should be created.
... that actually was both wrong, a performance failure and has been
there since the original checkin.
Updating the cached style data absolutely does not mean clearing all
cached style data first. There's nothing to update then.
This adds the GtkCssAnimation class and the code needed to hook it into
GtkStyleContext. It takes the values out of the CSS "animation"
properties and does animations. See
http://dev.w3.org/csswg/css3-animations/
for details.
Note that the code for starting and stopping animations with widget
visibility doesn't work yet.
... in the case where no change of the DOM tree actually happened.
We don't do anything yet with that information, this patch just
correctly computes it.
