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

[Matthias Clasen <matthias clasen gmail com>]

On Sun, Dec 19, 2010 at 2:38 AM, Tristan Van Berkom

>
>  a.) Do nothing to GtkCellArea, set the "align" cell property for
>      cells in the app chooser to FALSE (like the attached patch
>      does, as an example).

I think we have to change the default for align to FALSE, or at least
make treeviewcolumns set it to FALSE by default, for compatibility, no
?

There should be no need to add cellarea-touching code to the app
chooser to get the same behaviour as in 2.x...

>  b.) I was thinking we could implement a separate "fixed-size"
>      cell property for GtkCellAreaBox that would still cache the
>      largest size of the cell for a given series of requests.
>
>      Setting a "fixed-size" on a cell would achieve a similar
>      effect of setting "aligned" on a following cell, except that
>      following cells would not be aligned when that "fixed-size" cell
>      is invisible (unless the following cell is also set to "align").
>
> Option "a" comes with the disadvantage that rendering is technically
> slower (not visibly but cell sizes are recalculated for every render).
>
> Option "b" requires say... an evening of hacking that I'm willing to
> do to get things working better, if we go with option "b" I would change
> the default behaviour of gtk_cell_layout_pack_start/end for box areas
> to be "align" FALSE "fixed size" TRUE, that would be a more exact match
> for the behaviour of GTK+ 2.x I suppose.

Not sure I fully understand what fixed-size is supposed to do. But
I'll point out that there should be some optimization possibilities
for invisible cells (no need to size allocate an invisible cell,
unless there are alignment constraints).

> I've been wondering if maybe some kind of GtkTreeModelFilter feature
> could be done here, i.e. create groups in a filter and virtually expose
> the header rows from there, the filter could sort out and "group" the
> underlying data into groups and virtually add rows...

Sounds like a cleaner appoach. You'll probably still need some data in
the underlying module to indicate the groups. And you'll still need to
set up separate cell renderers and juggle their visibility. So, not
sure it is going to be a big win in terms of simplicity.