On Tue, Jun 24, 2003 at 06:27:11PM -0400, Ian Schorr wrote:
> Currently the gtk-clist code appears to automatically choose "optimal"
> column widths (based on the width of the cell itself) after loading a
> new file.
...and, unfortunately, not based on the width of the cell's title, as
the "optimal" width might not be wide enough to show the cell title.
> In my own experience, I often load traces that contain or or
> more frames that have "Info" cell widths of several thousand pixels
> (long CIFS filenames, many streamed NFS requests/replies, etc, end up
> containing quite a few characters). This means that the Info column is
> auto-sized to several thousand pixels as well, either forcing me to
> spend a long time manually resizing the column, or preventing me from
> using columns on the right-side of the Info column.
>
> I'd like to suggest capping the auto-resize to something reasonable.
I'd like to suggest getting rid of auto-resize completely. :-)
Some problems with auto-resize as it's currently implemented:
the cell title issue I mentioned;
the "making columns wider than you might want" issue you
mentioned.
Those can probably be fixed, but here are some problems with auto-resize
that might be inherent in auto-resizing:
It requires Ethereal to generate, for every column to be
auto-resized (not all columns are auto-resized) whose maximum
size can't just be computed from the maximum numerical value for
the column, the text for that column, for every packet. Right
now, the GTK+ widget we use requires Ethereal to compute the
text for every column, but (with some changes, e.g. support for
fast random access to packets in a gzipped file, which should,
according to somebody I talked to, be doable if we save copies
of the compression dictionary values at various points in the
file) I'd like to use widgets that call back to the Ethereal
code to get column text, and not generate that text. This would
save a significant amount of CPU time and memory.
It requires Ethereal to compute, for those columns, the pixel
width of the column values for each row. At least as I infer
from this note from a message by Olivier Abad:
- the CList widget in gtk2 is slower, probably because gtk2 uses pango
to display text (various messages on gtk-app-devel confirm this)
that's more expensive in GTK2 than in GTK1. (Unfortunately,
this *other* note:
- the ListStore/TreeView replacement is painfully slow (also confirmed
by gtk-app-devel archives).
indicates that the obvious widget to use, in GTK2, for the
previous paragraph's problem is slow. I just hope widgets such
as Cocoa's NSTableView, QT's QListView, and so on are reasonably
efficient if you have hundreds of thousands, or more, rows....)