Re: Auto-resizing columns in Really Big Tree Views
- From: Guy Harris <gharris flashcom net>
- To: jrb redhat com
- Cc: Guy Harris <gharris flashcom net>, gtk-devel-list gnome org
- Subject: Re: Auto-resizing columns in Really Big Tree Views
- Date: Tue, 21 Nov 2000 01:07:15 -0800
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... (-:
> <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
> 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
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.)
] [Thread Prev