Gtkmm2Ext::Pane::on_add() uses a pointer to a std::vector<> element
in the destroy notify callback. If the vector is modified, that pointer
becomes invalid.
Add 2 widgets "A", "B". remove "B", add another one "C".
Now if A is destroyed, notify_child_destroyed(PTR) points to
invalid memory and not to "A".
* enforce minimum size of child widgets
* honor manually set child-minsize in size-requests
* ignore hidden children (eg. VCA)
* clamp divider position (instead of just ignoring out-of-bounds moves)
Gtk::Widget_Class::dispose_vfunc_callback calls hide() which invokes
Pane::handle_child_visibility which calls Pane::reallocate which
tries to get the allocation of the widget being destroyed.
Windows key generates Mod4+Super (at least with the version of Gdk we use on
linux) so for bindings using the Windows key to work, GDK_SUPER_MASK has to be
added to modifier mask.
The code computing the position of the popup menu used to compare the
given string to each MenuItem::get_label() result, but that method
actually replaces the content (child) of the MenuItem if that child is
not already a Gtk::Label. In particular, this breaks menu separators.
Avoid the issue by checking by hand if the only child of the MenuItem is
a Label, and directly compare the label text.
Because all uses of the function positioning menus anchored to a widget
were as callback argument to Gtk::Menu::popup() where the caller needed
to correctly bind arguments, this led to repeated and a bit obscure code.
Wrap the logic into an helper function that takes care of all that, and
update the callers.
In some circumstances UI::flush_pending never returns, and all UI
interactive ends up being driven by
while (gtk_events_pending()) { gtk_main_iteration(); }
This has various implications depending on the caller and usually results
in a crash at session-close or exit.
Code to check if we were to close to an edge (for window resizing) blocked all divider setting,
because it would be called with a current widget allocation of 1x1
