Re: GtkSpreadTable ('spread-table' branch)

[Tristan Van Berkom <tristanvb openismus com>]

On Fri, 2010-10-08 at 12:13 +0200, Murray Cumming wrote:
> On Thu, 2010-10-07 at 12:37 +0900, Tristan Van Berkom wrote:
> > Hello list again,
> >    Now for the introduction of GtkSpreadTable (still open for
> > a better name for this widget).
> > 
> > What the spread table container does is takes a linear list
> > of widgets, which can be of variable size and spread/distribute
> > the widgets as evenly as possible according to their size
> > across a fixed number of rows or columns. Thus requiring the
> > smallest size possible while maintaining the fixed number
> > of columns or rows.
> > 
> > For instance when oriented vertically, widgets will be listed
> > top-down with the first widget in the top-left corner and the 
> > last widget on the bottom right; widgets will be lined up in 
> > such a way to require the least height as possible.
> > 
> > This widget is the one that actually meets the requirements 
> > for Glom[0].
> > 
> > To get a better idea of how this works you can checkout and 
> > build the 'spread-table' branch I added to GTK+ yesterday... 
> > fire up the ./tests/testspreadlayout demo.
> 
> Some quick links might be helpful
> http://git.gnome.org/browse/gtk+/log/?h=spread-table
> http://git.gnome.org/browse/gtk
> +/tree/gtk/gtkspreadtable.h?h=spread-table
> 
> I have already wrapped this in a branch of gtkmm, and even used it in
> Glom instead of my custom code. It seems to work fine for me.
> 
> Some small suggestions:
> 1.
> I think lines should be lines_count.
> 
> 2.
> I'd like a get_widget_line(GtkWidget*) function so I can discover what
> line (column in my case) the widget is currently in. I'd like to query
> that whenever the allocation changes, so that I can align some child
> widgets (children of HBoxes in columns of the GtkSpreadTable) via a
> GtkSizeGroup. Obviously I only want widgets in a GtkSizeGroup (so they
> have the same width) that are in the same column.

I suppose they could even be read-only child properties,
in this way we could cache the current line number and 
notify the changes when one widget gets placed on an new line
(an unallocated widget would always be on line -1).

Then you could just watch when the widget jumps from line to line.

However I wonder if changing some if the internal widget's size
groups may effect the overall requested width of that column...
and in the worst case you end up with a situation where:
  - Allocation happens
  - Change size groups in consequence
  - Size group changes widget requests
  - Widget's get reorganized into different
    columns as a result of the new size-grouping. 

Maybe it wont happen so long as you are playing with smaller
sizes, but it may be recommendable to just size group widgets
in all columns equally (I suppose experimentation will tell).

Cheers,
       -Tristan

> 
> This is fairly unusual, but this is the first widget that has such
> dynamic layout so you can't predict at compile time where the widgets
> will appear in relation to each other.
> 
>