Re: Minutes of the GTK+ Team Meeting - 2010-12-14

[Matthias Clasen <matthias clasen gmail com>]

On Sat, Dec 18, 2010 at 1:09 AM, Tristan Van Berkom
<tristanvb openismus com> 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.