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

[Tristan Van Berkom <tristanvb openismus com>]

On Sun, 2010-12-19 at 11:42 -0500, Matthias Clasen wrote:
> 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).

Another idea is, if hypothetically we were to export a 
RowIsGroupHeaderFunc() (same kind of syntax as RowIsSeparator())
then the treeview column could even use a separate GtkCellAreaContext
to request the sizes of group header rows.

However I think that's too hasty a decision to make on the general
direction of how group headers should work, so I would rather just 
go with implementing a "fixed-size" cell property for the box for now.

Cheers,
          -Tristan

> 
> > 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.