Height for width treeviews

[Tristan Van Berkom <tvb gnome org>]

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