because filesystem readdir order is indeterministic.
Without this patch, building openSUSE's balsa package
had variations between builds in /usr/share/balsa/icon-theme.cache
When calling PickColor on org.gnome.Shell, we get back an "a{sv}", which
GDBus provides to us as "(a{sv})".
At the minute we're not unpacking this tuple, and so picking fails with
messages like:
GLib-CRITICAL **: 13:38:19.439: g_variant_lookup_value: assertion 'g_variant_is_of_type (dictionary, G_VARIANT_TYPE ("a{s*}")) || g_variant_is_of_type (dictionary, G_VARIANT_TYPE ("a{o*}"))' failed
Gtk-WARNING **: 13:38:19.439: Picking color failed: No color received
Let's unpack it.
The additional assignment to the old result variable just adds an
indirection even though we know the point where we assign it in all
cases. Just pass the values out and return in those cases instead.
Previously, GtkBin was only snapshot'ing its one and only child, but
nowadays it doesn't implement snapshot at all and the default
implementation in GtkWidget just snapshots all child widgets, which is
exactly what the implementation in gtkmodelbutton.c was doing.
Since the original implementation was likely based on GTK+ 3, the change
in default visibility might have not been considered, which results in
all rows suddenly sporting a visible spinner when opening a fresh file
chooser.
Unparenting a GtkListBoxRow can drop its last reference, which
will free its memory. Right after unparenting, though, we were
accessing the row's iter - which assumes that the row is still
alive. This causes a crash when, for example, binding two or
more models to the listbox.
Fix that by storing the iter in a variable, and not trying to
access it after unparenting. After unparenting, the variables
that are potentially garbage were explicitly assigned NULL for
clarity.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1258
bindings now treat identifiers and strings the same way.
The only difference was that one allowed lookup of enum/flags by name
while the other didn't and g_warning()ed. Now both work.
Perform scrollbar visibility checks through a motion controller,
always based on GtkScrolledView-relative coordinates. The captured
event handler remains though, for a tiny bit of GDK_SCROLL event
handling.
Use a distinct key controller so we correctly handle navigation
across matches and search cancellation. As the events are forwarded
to the search_window, those need to be pushed down the entry manually.
CSD titlebar are included in the focus-chain. The logic used makes sure that the
initial focus avoids the titlebar, but tabbing around will eventually get there.
This logic fails in case the window has no other focusable widgets apart from
the ones in the header-bar. If this happens keynav focus will be lost. To handle
the above scenario, we need to fallback to focus the header-bar (if any).
Fixes: https://gitlab.gnome.org/GNOME/gnome-software/issues/404
Drop the drag-highlight and drag surfaces. The highlighting
is broken anyway, so just drop it for now. And for dragging
the header button, we can just position it properly, that
works just as well as this reparenting approach.
