This only used by luck before. We are changing a property from the
::notify handler for that property. Now that GtkRevealer is notifying
the property when it stops animations on unmap, we end up in a life
lock situation where we never make it out of the notify queue.
Fix this by not restarting the animation if the widget is unmapped.
Depending of float rounding during target calculation, the size of the
GtkRevealer can be set to zero will the animation is not finished.
If the GtkRevealer is in a GtkPaned, it will be hidden and so the animation
will be stopped before it is finished.
In this case, force the emission of the child-revealed signal to let
client code know the animation is finished.
https://bugzilla.gnome.org/show_bug.cgi?id=765973
This was another very frequent use of qdata. Since we typically
have only one or two display objects, storing the display-settings
association in a simple array is faster than using object data
or a hash table.
Use of g_signal_handlers_disconnect_by_func() needs to do more work than
necessary to find all the matching handlers. Instead, just hold on to the
signal identifier and remove it directly so we hit the fast path.
Not terribly ground breaking in terms of performance gains, but its done
enough to be worthwhile.
https://bugzilla.gnome.org/show_bug.cgi?id=766049
Christian Hergert reported seeing webkit crashes with recent
GTK+. The stacktrace points at the CSS machinery calling into
GtkSettings to get the font name, and then getting surprised
by a property notification that triggers style validation.
To avoid this, query the font name xsetting right away when
we get set a screen.
The active keyboard grab can be spared then. This way the passive
key grabs allow other key combinations (eg. alt-tab) that are not
mandatory to grab here.
This will almost certainly overwritten before the widget gets
to the screen, but while we are doing this, we might as well
use the same state that we initialize the widgets state to.
Instead of creating 2 pango layouts in every draw() and on in
_get_content_size (and calling into gettext twice in both cases), just
keep the layouts around and create them in only one place.
I was somehow under the misconception that we'd get GdkEventSettings
events for all the xsettings at startup. That is not in general true,
so we need to make sure that we check for the xsettings value before
we use them, or derived fields. Update all the private getters to
do so; and fix settings_update_font_values() to cope with font
descriptions that might miss the family or size.
I mistakenly assumed that gtk_settings_init was already doing
something to trigger a notify for all properties. It doesn't,
so we have to ensure that settings_update_font_values() is
called at least once.
https://bugzilla.gnome.org/show_bug.cgi?id=765966
