Re: Height for width treeviews

[Matthias Clasen <matthias clasen gmail com>]

On Wed, Jun 30, 2010 at 12:16 PM, Tristan Van Berkom <tvb gnome org> wrote:
> Greetings,
>   Last couple weeks I've been working on the height-for-width
> cell renderer api and now I have an intelligible branch for review:

Some initial feedback, from playing with that branch for a few minutes:

* I don't think your scrolledwindow cycle detection hack will work in
general. What if the treeview is not a direct child of the
scrolledwindow ? Eg there could be a vbox in between.

* Do we need a similar hack for other 'async allocating widgets, like
the text view ? Would it therefore not make more sense to have the
hack in the scrolledwindow code ?

* Toying with your 'wrapping treeview' demo, and making it as narrow
as possible, I notice 'demonstrate' overlaps with the icon next cell.
Shouldn't that line have determined the minimum width of that cell,
preventing it from shrinking any further ?

* Looking at the list store example in gtk-demo, and sorting by
clicking on the headers, there is an off-by-a-few-pixels delta
between the header and the sort column background. The delta grows as
you sort by columns further right, so I think this may be some missing
per-column padding, or something.

* Open the file chooser in the pickers example for the first time, I
notice the first 30 or so files getting a bigger height than the rest.
Changing the sorting mixes these different-height rows into the others
but doesn't fix their size. Changing directories back and forth does.
I also notice that the name column gets too much width, and refuses to
let me make it any smaller.

* Using tests/testtreecolumns, and adding 2 columns to one of the
windows, the column resizing is wonky. If I start dragging the
separator, I have to go almost all the way to the right, then the
column jumps. Once it jumped, it follows the pointer further to the
right, but if I move too far left, it jumps back.