Re: Auto-resizing columns in Really Big Tree Views

[Guy Harris <gharris flashcom net>]

On Tue, Nov 21, 2000 at 03:04:54AM -0500, jrb redhat com wrote:
> This is an appropriate place for such requests, though perhaps an
> inappropriate time as we are trying to lock down GTK+ 2.0.

I figured as much.  Alas, I haven't had all that much time to spend on
looking at the "virtual clist" stuff....

> I'll try to help, though... (-:

Thanks.

> <offtopic personal opinion>
> I really don't like the 3 flexible pane view.  Is there any way you can
> make the packet dump either "fixed", or place it elsewhere?
> </offtopic personal opinion>

"Flexible" and "fixed" in what sense?  In the sense of size?  Currently,
if you resize Ethereal's main window, the middle pane resizes, but not
the other panes.

> Yikes!  That's a lot of rows.

Sure is.  Every now and then somebody reports that Ethereal dies if they
hand it a large capture file; right now, most of the memory is, I think,
strings allocated for the GtkCList (which came as a surprise to me when
I went looking for all the memory used to handle really large capture
files).

> I'm not 100% sure what your saying here, but it seems to me like you
> want to avoid the initial size calculation altogether.  That is not an
> option, as the GtkTreeView expects to know where every column/row is.
> I'm afraid there's no way to get around walking the model at least
> once.  Is there no way you can speed this up?

I suppose I could have Ethereal supply semi-bogus data (with the correct
width) for some columns as it's adding rows:

	supply N digits of "0" for the packet number if the packet
	number would have N digits (the font used is a fixed-width
	font);

	do something similar for time stamps;

	supply fixed-length constant strings for the address columns
	(which are fixed-length in Ethereal anyway);

and then - *if* I can then tell the TreeView that the model has changed
the data it supplies (which I presume can be done) - have it supply the
real data.  (For the protocol column, I want to supply real data, and
I think I can avoid copying strings to a column-data buffer in most
cases.  For the Info column, I could supply some default string of
blanks, and resize it on the fly as appropriate.)