Use foreach() instead of forall() to find the child's siblings
because internal children of subclasses have no sibling relation
to the box' children. Also deal with the subclass failing to
implement get_path_for_child(). This caused an infinite widget
path invalidation loop of sorts with GimpMessageBox, which is a
vertical box with a decorative icon to the left.
Fixes#640741 - gtk_tree_view_column_get_cell_position() seems to be broken
It is supposed to return the offset within the column, but returned
the offset within the tree, changed by allocation.x of the column's
button (which I don't really unserstand and was clearly not working).
The handling of the module lists is a bit confusing here. There is
a global list that is populated with initial modules from GTK_MODULES,
and then there is a second list that is suppposed to hold the modules
loaded from the gtk-modules xsetting, which we attach to the GtkSettings
object. The blacklisting caused us to put the wrong modules into the
second list, and mess up the module refcounts, eventually double-freeing
memory when the setting changes repeatedly.
https://bugzilla.gnome.org/show_bug.cgi?id=659966
The following assertion was triggered in model_row_inserted() because
iterate_thru_children() modifies the parameter tree_model before passing it to
traverse_cells().
Gtk-CRITICAL **: gtk_tree_path_compare: assertion `b->depth > 0' failed
The stack with the bug was:
#0 gtk_tree_path_compare at gtktreemodel.c
#1 traverse_cells at gtktreeviewaccessible.c
#2 model_row_inserted at gtktreeviewaccessible.c
This patch calls iterate_thru_children() with a copy of the path so that the
original is not modified.
This way, all rows have the same height. It has 3 advantages:
1) No actual computation is necessary to compute the size of the cell.
This speeds up the list tremendously (filling out the list goes from
25s to 3s).
2) Buggy fonts don't mess up the list anymore with their weird sizes.
Instead, they are clipped / empty space is added.
3) Buggy fonts look more buggy. So their use is hopefully discouraged.
With absolute sizes, Pango is way better at getting the actual sizes of
the fonts to match up. It's a bit harder to compute a proper value for
this, whcih makes the code ugly, but as long as it works better...
This way, we can find fonts way quicker as we only need to create font
descriptions for fonts with matching families. Most importantly, we're
rather quick in the "the font doesn't exist" case.
