Height for width treeviews

[Tristan Van Berkom <tristan van berkom gmail com>]

Greetings,
    Last couple weeks I've been working on the height-for-width
cell renderer api and now I have an intelligible branch for review:

http://git.gnome.org/browse/gtk+/log/?h=native-layout-incubator-2

This branch was created off master and includes a set of
5 or 6 commits (so this branch currently has no bugfixing
distortion, just clean commits).

So in brief, the patch includes:
   - The internal allocation loop used by GtkBox has been refactored
     to be a reusable function gtk_distribute_natural_allocation().
   - The new GtkCellSizeRequest interface
   - GtkCellRenderer virtualizes the return of ->get_size() and falls back
     on ->get_size() implementations for GtkCellSizeRequest calls (basically
     a deprecation with a fallback like GtkWidget does for GtkSizeRequest).
   - GtkCellRendererText does wrapping text and height-for-width
   - GtkTreeView/GtkTreeViewColumn now request and allocate in a
height-for-width
     manner (height-for-width cannot be implemented directly here as that
     is calculated asynchronously).
   - GtkScrolledWindow gets a little cleanup and a bugfix (fixed a typo where
     requesting extra space for the scrollbars)
   - GtkExpander now requests and allocates height-for-width
   - Tests for treeview and expander added to tests/testheightforwidth.c

What's left in the native-layout branch that didnt make it:
   - Some work towards improving the plug/socket api in
height-for-width conditions
   - An initial attempt at getting GtkComboBox/GtkCellView to behave correctly
     (wrapping/ellipsizing combo boxes)

Whats still generally TODO in height-for-width land:
   - GtkTable does not regard natural sizes
   - GtkToolPalette does not regard natural sizes
   - GtkFrame needs the same kind of treatment as GtkExpander
   - GtkIconView should do something similar to GtkTable but with cell renderers
     and with its icon wrapping technique.
   - GtkTextView has bugs when placed in a scrolled window - these bugs exist
     since before GtkSizeRequest but can probably be better addressed with the
     new api

A new interesting problem:
   Now that scrolled window children (or scrollable widgets) can be
height-for-width,
an interesting feedback loop becomes possible when the extra allocated width of
a vertical scrollbar can effect the height of the widget in question
enough to make
the vertical scrollbar again toggle visibility... thus again
reallocating the old width
with the old scrollbar visibility ... forever.

This is particularly a mess for GtkTreeview because it must obviously calculate
it's requested height asynchronously - which means the parent scrolled window
has no way to differentiate a detected feedback loop from a valid child size
renegotiation based on a content change.

Currently in the branch this is handled by the treeview which watches the
parent scrolled window size and tracks it at allocate time, it may work well
if handled with extreme care but essentially a better api should be invented
for GtkScrollable children.

Well I think that's all for today...

Cheers,
            -Tristan