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. Just a thought, -Tristan _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list