Added a few apis,
- GtkCellAreaContext get_preferred_height_for_width &
width for height apis and vfuncs, this lets the icon view
request the collective (and aligned) height for width for
a said row.
- gtk_cell_area_copy_context() this creates a duplicate of
an already created and requested context, this way the icon
view uses a global context to request the widths of all rows
and then makes a copy with all the stored alignments and
uses a separate copy to calculate the height and alignments
of each row separately.
What this means is basically that a vertically oriented GtkCellAreaBox
will render cells properly even if the height is not constant for every
for of data in the said GtkCellAreaContext (i.e. the height was not allocated
by gtk_cell_area_context_allocate).
This is done completely on the fly and so is much more heavy duty
at render time (considerably slower but not visibly noticable in
lightweight views like GtkTreeMenu). Note that cell alignments
are not possible in an unallocated orientation, each row of data
individually receives only enough space to render the independant
row and no space is reserved for alignments if the size is not
a constant size across rows in the same context.
- gtk_cell_area_context_get_height_for_width()
- gtk_cell_area_context_get_width_for_height()
- gtk_cell_area_context_push_height_for_width()
- gtk_cell_area_context_push_width_for_height()
- gtk_cell_area_context_flush_height_for_width()
- gtk_cell_area_context_flush_width_for_height()
- Contextual size changed signal
All of these are not really important for the CellArea to operate
and not of any real consequential value to the user (the user can
accumulate the returned values from height-for-width requests
and do as they please with it).
This is so that treeviews can have some columns oriented vertically and
some horizontally, usually the column will only allocate the areas
width, having vertical columns without fixed row heights just means
it's slower to render.
