On Sat, Dec 18, 2010 at 1:09 AM, Tristan Van Berkom <[email protected]> wrote: > On Fri, 2010-12-17 at 19:33 -0500, Matthias Clasen wrote: >> Tristan, >> >> another thing (that I believe Cosimo already pointed out) is that the >> new cell area code seems to not quite get interaction between cell >> data functions and size allocation right. >> >> You can see the resulting breakage in testappchooser. The treeview in >> the appchooser uses a separate cell renderer for the heading text, and >> uses a cell data function to make it visible only for rows that are >> supposed to be headings (this is a very common pattern, expect many >> things to break in similar ways). After the cellarea merge, the >> heading cell renderer seems to always get its size reserved, even in >> rows where it is invisible. > > Ah interesting. > > Currently this is happening because by default all cells are packed > with the "align" property set to true. > > If we were to make the second cell appear "first" in the case the > first cell is invisible, it would be a lie to say that that cell > is "aligned" with adjacent cells. > > Unaligning the cell following the invisible cell will make the > second cell cover the first cell's area when invisible, but not > following cells, maybe we need some different semantic for that > kind of thing (thinking...)
It seems we need some kind of grouping for these alignment considerations. In the 2.x world, all cells in a column could use the space of the column, depending on the visibility of the other cells in the same column, but cells could not grow across column boundaries. _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
