On Wed, Feb 07, 2007 at 03:37:07PM +0100, Emmanuel Briot wrote:
I do agree with your analysis that the other modes do not make sense, but if
things work anyway shouldn't it just be documented that best practice
recommend using fixed width mode, but have the code not enforce it ?
Maybe, I am
On Wed, Feb 07, 2007 at 10:06:13AM -0500, Morten Welinder wrote:
You would measure cells only as they become visible and adjust the width
of the columns as needed.
That would probably mean that the columns will be busy resizing as you
are scrolling. I am not sure if that is really nice ...
Morten Welinder [EMAIL PROTECTED] writes:
That depends on the data and how much we have seen before, but if
we initially did a fair-sized sample -- last I looked we were doing 1000
rows -- then the probability is low and hence it is not annoying.
If you did that, then you could also
On Wed, Feb 07, 2007 at 12:58:18PM +0100, Emmanuel Briot wrote:
The assertion above checks that all columns are also using a fixed sizing.
The
comment doesn't really indicate *why* this was necessary though, and that is
change compared to older versions of gtk+ 2.4.
Note that this change
Which other resizing mode would you want to use for your column?
AUTOSIZE doesn't make any sense, the point of fixed height mode is to
speed up GtkTreeView by not measuring every row.
AUTOSIZE. Or maybe GROW_ONLY.
You would measure cells only as they become visible and adjust the width
of
