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

[Tristan Van Berkom <tristanvb openismus com>]

On Mon, 2010-12-20 at 03:39 +0900, Tristan Van Berkom wrote:
> 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).

Ok I finally did this.

It's still sitting on treeview-refactor branch...

With the new code GtkCellAreaBox allows cells to
either be aligned, fixed in size, or both.

A cell, if not aligned, will show up directly
after the leading cell's allocation for that
specific row.

Fixed size cells and non-fixed size cells can
follow eachother, an aligned cell that follows
other cells will always be positioned at the
same place in all rows.

I added individual controls in tests/testtreeedit
to control "align" and "fixed-size" separately
(if that can help to clarify the difference).

Now by default cells are packed with "fixed-size" TRUE
and "align" FALSE, this matches the old treeviewcolumn
behaviour exactly.

testappchooser in treeview-refactor branch works exactly
as expected now.

Cheers,
        -Tristan

> 
> > 
> > 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.
> 
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list