Re: Auto-resizing columns in Really Big Tree Views

[jrb redhat com]

Hi there,


Guy Harris <gharris flashcom net> writes:

> (As the tree view stuff is still under development - and as what I'm
> asking for may require changes to it - I'm assuming, perhaps
> incorrectly, that this question is best asked on "gtk-devel-list" not
> "gtk-list".)

This is an appropriate place for such requests, though perhaps an
inappropriate time as we are trying to lock down GTK+ 2.0.  I'll try to
help, though... (-:

> It has 3 panes (like all three of the analyzers mentioned); the topmost
> pane is a list of all packets (currently implemented with a GtkCList),
> the middle pane is a tree showing a the fields in the currently-selected
> packet, and the bottom pane is a hex/ASCII dump of the data in the
> currently-selected packet.

<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>

> In Ethereal, I'd like to have some columns in the packet-list pane
> auto-resize, from the user's point of view, *without* having the tree
> view widget iterating over all the rows.
> 
> I want to avoid that because there could be a *LOT* of rows (one packet
> capture has 138,673 packets in it; I really don't want to have the tree
> view widget go through all 138,673 rows call back to the model - which
> would be implemented by Ethereal itself, rather than by a data structure
> storing the text for the columns, as storing the text for all those
> columns, rather than generating them on the fly by dissecting the packet
> when it's to be displayed, significantly increases the memory
> requirement for that capture file).

Yikes!  That's a lot of rows.  I have tested the GtkTreeView with
110,000 rows, and it seems to work fine once it has been realized.  The
initial size calculation stage was a little slow.  This calculation
stage is unavoidable, though.   When you first display the widget, you
will need to go through all 138,673 rows in order to calculate row
offsets.  I don't see anyway around this with the current design.

> It looks as if "gtk_tree_view_calc_size()" will, in fact, iterate over
> all rows in the model, and, for each row, iterate over all columns in
> the view.

Pretty much -- I cache the height.

> Is there any way to have Ethereal supply the column widths, which it can
> do for most columns, *and* have the widths it supplies take into account
> the widths of the titles, so that if, for example, you have a capture
> with one packet in it, so that the largest value of the "packet number"
> column is 1, it can supply a width large enough to hold the title "No."
> for that column?

Basically, you can have three different modes for columns.  Autosize
(which _will_ be slow with massive packet information), Fixed size, and
resizable.  Resizable will give you pretty much the behaviour you want - it
only grows the column when it hits a wider column.

> For one column, the "packet information" column, which give a short
> summary of the packet contents at the topmost protocol layer, it won't
> know the column width; I'd like to avoid, when reading the capture file
> in, generating the data in that column, as that would significantly slow
> down reading large capture files.  Instead, I'd like, if possible, to
> resize that column *when it's displayed*, so that if you scroll the
> packet list down and make visible a row with a longer "information"
> column than any rows that have been seen so far, the column gets wider. 
> (That column is probably going to be the rightmost column, so the visual
> effect should only be the appearance of, or a change in the length of, a
> horizontal scrollbar.)

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?

Sorry I can't be more helpful, but I'm not sure what answer you're
looking for...

Thanks,
-Jonathan