Re: GtkSpreadTable ('spread-table' branch)

[Tristan Van Berkom <tristanvb openismus com>]

On Fri, 2010-10-08 at 15:38 +0200, Murray Cumming wrote:
> On Fri, 2010-10-08 at 21:23 +0900, Tristan Van Berkom wrote:
> > On Fri, 2010-10-08 at 14:08 +0200, Murray Cumming wrote:
> > > On Fri, 2010-10-08 at 20:36 +0900, Tristan Van Berkom wrote:
> > > > 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).
> > > 
> > > Yeah, I saw the risk of an endless loop, but maybe I can prevent that in
> > > my code. Or maybe it will just be one extra relayout. My existing code
> > > actually has a hard-coded concept of two horizontally-aligned items in
> > > each column, so it knows about that constraint already. But that's very
> > > specific behaviour.
> > > 
> > > Alternatively, is there just some way to find a child GtkWidget's
> > > position in a GtkContainer? Then I wouldn't need extra API.
> > > 
> > 
> > You can use gtk_widget_translate_coordinates() for that... but it 
> > will leave you with alot of guessing (observing widget allocation
> > sizes in the child list etc).
> > 
> > I think an API will make your code much cleaner, maybe it would
> > help if at least you got to step in /before/ the allocation
> > actually happens.
> > 
> > i.e. the same API could be:
> > 
> > guint gtk_spread_table_get_child_line (table, child, size);
> > 
> > where it would return: the column 'child' would fall into
> > if 'table' were allocated 'size' width.
> > 
> > This could potentially give you a chance to shift size groups, 
> > run some tests with the above api and then actually allocate
> > the table's size after you know it's safe.
> 
> So I'd start with the child's currently allocated-size?
> 

Well, unfortunately size-allocate is a RUN_FIRST signal so
that doesnt give you much play without writing an ultra
simple custom GtkBin container.

I was thinking more along the lines of using the incoming
allocation before applying it to the spread-table.

If you write a GtkBinClass for the purpose of parenting
your 'spread-table' and having some knowledge of how
it needs to size-group... then at size-allocate time
you could observe what the effects of allocating the
child spread-table would be... and sort-out size-groups
before actually allocating the container.

Maybe in the worst case, you can even detect where some
recursion would happen, and test some 'larger-than-allocation'
sizes... and then you queue a resize on the GtkBin and
be sure to request a large enough width to ensure no
deep recursions will happen ?

Again, just some ideas... it seems to be a tricky
problem.

Cheers,
          -Tristan