Since GtkTreeMenu became a private class only used by GtkComboBox, all
this test actually did was to show a ComboBox constructed with a custom
CellArea. Now that the latter is no longer possible, the test just shows
a handful of settings that do nothing. Just test GtkComboBox directly.
Currently hiding destroys the wl_surface and all related interfaces,
(including the gtk_surface1) so the next time the GdkWindow is mapped,
we don't bother to set the DBus properties. Toggle the check off so
it's actually issued again after the GdkWindow gets a gtk_surface1.
https://bugzilla.gnome.org/show_bug.cgi?id=773686
The new CSS border-spacing does what Grid::(row|column)_spacing and
Box::spacing already did, i.e. controlling the space added between child
widgets, so it’s not a replacement for Container::border-width.
Now that priv->area is guaranteed to be constructed by us, and not
passed in by a user, we can move it to the .ui file and stop manually
managing its lifetime altogether. And once the area is there, we can
move the menu there too (and stop pointlessly destroying/rebuilding it).
We already have cell_layout_is_sensitive() to get whether at least one
cell in a Layout is sensitive, which we need because CellLayout/View
do not implement foreach(). So, since we wrote that, we can use it to
check our CellArea too, instead of doing foreach with a custom callback.
It was looping over all items, not breaking out when it found the first
selectable one, and then selecting the _last_ selectable one (if any)
found. So, it did exactly the opposite of its name. This made me quite
baffled when opening a submenu with right-arrow put me at its last item.
Originally, the loop set to_select and broke if the current item was
selectable and not tear-off, meaning that it would correctly select the
first suitable item. However, when tear-off functionality was removed
in commit 4ed9452e90, so was the break.
