This gets rid of a bunch of awkward transitions. It's not a perfect
solution to the problem of "should we transition from this state" but it
gets rid of the ugliest offenders.
If this is done on dispose(), the widget may be destroyed (and its
controllers list NULLified) within _gtk_widget_run_controllers(),
causing warnings/crashes when it just tried to hop on the next
controllers.
Freeing the controllers here should be a safety net for implementations,
so it also makes sense to do this late. The widgets that choose to
free their controllers on dispose can still do so, and get
_gtk_widget_remove_controller() called for these as an indirect result.
g_utf8_get_char_validated() may return -1 or -2
return type is gunichar(guint32)
Therefore such checks like 'gunichar < 0' or 'gunichar > 0'
are always 'false' or 'true'(except when gunichar == 0).
Signed-off-by: Maks Naumov <maksqwe1@ukr.net>
https://bugzilla.gnome.org/show_bug.cgi?id=742774
If a gtk_style_context_invalidate() is called on a widget's style
context (which nobody should ever do, sheesh!) and we're animating, stop
the animations.
Fixes crashers in Nautilus.
When we get a leave event, we need to remove the over bit,
since we may not get motion events that tell us when we lose
proximity, but we don't have to fade out right away - that
will happen on its on due to inactivity a bit later. Having
the indicator stay visible for a bit feels more relaxed.
Since gsize doesn't work as a typename in a ui file,
we have to be careful not to pass pointers to wrongly
sized variables when getting the guint64 values out
of the model.
https://bugzilla.gnome.org/show_bug.cgi?id=742664
We still use symbolic icons for Copy, Cut, and Delete operations inside
toolbars and some menus, so it's worth pointing to the symbolic icon
names in the deprecation notices.
https://bugzilla.gnome.org/show_bug.cgi?id=741969
We need to clear the cache manually on full revalidates because
_gtk_css_change_for_child() will clear the full revalidation flags.
And then gtk_style_context_update_cache() will not do the right thing
(which is to clear itself).
Because we can switch from animating to non-animating pretty much
anywhere, do the check for animations unconditionally instead of trying
to cram it into the correct if path (and failing).
We now cache the results of lookups on the parent GtkCssStyle. This
allows sharing styles between widgets (recursively). However, this
only works if the styles can't potentially depend on siblings -
neither directly via sibling selectors or via position pseudo-classes
like :first-child.
Unfortunately, Adwaita currently uses first-child a lot, and in
particular for labels, which are the most common widgets.
The big benefits of this change are both less CPU - due to not needing
to compute styles again - and less memory usage - due to sharing of
the styles between widgets. Here's some nonscientific numbers I
collected while pondering the usefulness of this patch:
glade glade widget
demo demo factory
runtime styles styles
Adwaita before 19.1s 5800 1150
Adwaita now 18.9s 3800 970
Adwaita hacked now 14.5s 3100 910
simple before 11.3s 5800 1150
simple now 10.8s 1300 590
Adwaita: Adwaita as provided by GTK
Adwaita hacked: Adwaita with the first/last-child for GtkLabel removed
simple: A 250 lines simple GTK theme I use for testing
before: This patch not applied
now: this patch applied
glade demo runtime: Starting glade opening a large file and closing it
glade demo styles: GtkCssStaticStyle objects after opening glade with
the large file as per inspector
widget factory styles: GtkCssStaticStyle objects after startup as per
inspector
Previously we looked at the save/restore state when determining the
parent. This is wrong in the case where we're updating the cache though.
So we now save the parent in the style info.
After the parent changes in commit
3a337156d1 we need to refresh the cached
styles after the current style. After all, they now depend on the base
style.
After 3a337156d1 style lookups still used
the parent context's style as the parent style, even though after a
gtk_style_context_save() the root style of the style context is the
proper parent.
Testcase attached.
Instead of keeping an animated style everywhere, we replace it with the
static style when nothing gets animated.
Apart from making the code cleaner, this gets rid of a bunch of animated
style values that do nothing but wrap a static style.
The only style that is animated is the style of the unsaved primary
node. So there's no need to create animated style objects for the other
ones.
There is a bunch of ugliness in the code currently. Further commits are
expected to fix them.
For now, this is only an implementation detail of the animated style.
The idea is to use GtkCssStaticStyle as the result of CSS queries and
then put a GtkCssAnimatedStyle on top that manages the animations. The
neat thing about this is that you can cache the static values.
GtkCssStyle is the base class to be used for all types of styles that do
exist.
GtkCssAnimatedStyle is the only implementation so far, that is exactly a
copy/paste of the old GtkCssStyle code.
I removed it in 14f5ce7108 because I
thought it was unnecessary, but it wasn't. When we build a tree like
this:
.matches ─┬─ .doesntmatch
└─ .alsodoesntmatch
We would get the changes for the .matches part returned. This is however
only right if that node of the tree contains results. If results only
exist with the child nodes (all of which don't match), then this part
should not match either.
GtkCalendar can have an invalid date — mostly at initialization. This
means that GDateTime construction may fail. We need to handle that case
gracefully, like the old code did.
This fixes the `notify` test suite, which started failing with:
/Notification/GtkCalendar:
GLib-CRITICAL **: g_date_time_get_day_of_week: assertion 'datetime != NULL' failed
inside the Continuous builder.
This is so we can detect crossing events on the scrolledwindow widget,
which can be useful for toggling certain behaviors or not depending on
whether the mouse is on the widget.
If the first of the month was falling on a Sunday, we would not
render any days of the previous month, and instead show two weeks
of the next month at the bottom. Improve this by showing one week
of each.
https://bugzilla.gnome.org/show_bug.cgi?id=301835
Changing font size does not cause widgets to update their size
properly anymore, since we forgot an invalidation flag. The
problem can be observed e.g. by running gtk3-demo and calling
gsettings set org.gnome.desktop.interface font-name "Cantarell 22"
