priv->trigger_event is never set, so it is always NULL. This means the
gtk_menu_popup*() methods use the current event. The only way to get any
other event to combobox_menu_popup() was from the button-press-event
handler I just removed, which would end up being the current one anyway.
So, bin priv->trigger_event & explicitly pass NULL to gtk_menu_popup*().
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.
combo_box_popdown() currently skips popping down our menu if it is NULL.
But the required call to this at end-of-life was in destroy(), by which
point dispose() already NULLed the menu, so Menu::popdown() would never
run, even if it should. Fix this by trying popdown() earlier in unmap().
Also, add a converse assurance that we don’t popup() while not mapped.
Even once we remove all the now-pointless NULL checks, destroy() was the
wrong place to call combo_box_popdown(), and unmap() is the right place.
Commit fdc0c6426b removed the appears-as-
list style property, & hence the ability to put the ComboBox into list
mode – but it left behind a pile of hijinks that were only used in said
mode & so were now doing absolutely nothing. This commit deletes those.
While doing that, I got carried away…so this also stops pointlessly type
checking popup_widget, as that can never be anything but a GtkTreeMenu.
It still checks for NULL everywhere, which shouldn’t be needed, but (A)
this commit is already too big, & (B) simply removing such checks where
they _seem_ unnecessary causes bad times. I’ll puzzle through that later
Commit fdc0c6426b for removing (partly!)
appears-as-list also deleted the code that propagated wrap-width to the
TreeMenu and thus put us into “grid mode”. This restores that code.
And as Benjamin noted, calling check_appearance() here is wrong, so bye.
i.e. when wrap-width > 0. This was only being done for non-grid cases.
So, ComboBoxes in grid mode did not indicate their selection when popped
up and required users to keynav from ‘nothing’ (at the top-left) to the
item they wanted to select. By selecting the active item in advance, now
it’s highlighted & acts as the starting point for keynav around the grid
GtkFileChooserButton installs a handler for the popped-up signal, which
refilters the menu, in order to hide the “(None)” item from the popup
if it was previously selected in the ComboBox. This oddity means that:
• Until recently, this item would be selected in the menu shell, which
would then be popped up and change the selection away from that item.
This was therefore redundant (more on which below!) but benign.
• After the patch for https://bugzilla.gnome.org/show_bug.cgi?id=771242
however, this causes a critical assertion fail, as now we stash the
originally selected item in a pointer so that it can be selected only
after realisation/popup – but by that stage, the model has just been
refiltered and the previous pointer no longer refers to a valid item.
This commit works around this problem by, after popping up the menu,
getting the active item again, in case a popped-up handler has gone and
invalidated the pointer to the active item that we saved before popup.
If a handler does this, everything done to find/use the original item is
pointless. But this avoids the ugly critical in FileChooserButton, while
not harming every other ComboBox that doesn’t mess with its model while
popping up (hopefully the vast majority), and it’s very difficult to
imagine a way to check if the active item is /going to/ be hidden later)
For a menu mode CB with wrap_width == 0 and an active item, that item is
selected in gtk_combo_box_menu_popup. Selection causes the MenuShell to
activate and hence take a grab. This was done before the menu was popped
up. A patch distributed in Debian sid - after being proposed on our BZ -
revealed that on the 1st popup of any such ComboBox, within grab_add,
the MenuShell's toplevel's GdkWindow is NULL. This causes a Gdk-CRITICAL
assertion fail on the 1st time opening any such CB, on Debian and if
that patch were merged to GTK+. By selecting after popup, we ensure the
MenuShell is realised before its grab_add and so avoid the critical.
https://bugzilla.gnome.org/show_bug.cgi?id=771242
Add a new ::measure vfunc similar to GtkCssGadget's that widget
implementations have to override instead of the old get_preferred_width,
get_preferred_height, get_preferred_width_for_height,
get_preferred_height_for_width and
get_preferred_height_and_baseline_for_width.
