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

That would not make it behave like columns used to behave, i.e. by
default every icon that follows a text renderer would not be 
aligned with rows above and below, instead it would follow the 
variable length text naturally (actually even in appchooser I can
see the UI is sub-par when just using unaligned cells, it only 
looks right when every app's icon happens to have the same 
width, browsing the whole list shows that the description text
is not well aligned).

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

Fixed size would make a cell behave exactly like it did with
GtkTreeViewColumn, i.e. it would reserve a fixed width for a cell
regardless of what row it's rendered in (but then a cell following
an invisible cell would take its position if it were not explicitly
aligned).

That differs from "aligned" inasmuch as an aligned cell's position
starts after the largest (or widest) collection of leading cells
(regardless if they are visible for a specific row or not).

Maybe "fixed-size" is not the best name for that concept, maybe
the names "align-size" and "align-position" would more clearly
express the functionality (not sure though, "align-size" doesnt
mean "align" to me, alignment is more about making cells appear
at the same position in every row I think).

Sorry I didn't foresee this in advance.

I'll try writing up a patch tomorrow.

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.