> It's our own modification of clist. We should have renamed it, to avoid
> symbol conflicts on Win32 and AIX.
There are other capabilities I might want to add to our private
column-list display, e.g. the ability to add and remove columns from a
live display, and the ability to have it call back to a per-clist
function to get the contents of a column rather than requiring it to
keep the text around; the former might let the "Columns" tab under
"Edit->Preferences" take effect as soon as you hit "OK", and the latter
could *considerably* reduce the memory requirements for large captures
(although, given that the CList scrolls as you drag the scrollbar slider
- which I consider a feature, as apps that only move the
scrollbar-controlled object when you release the slider annoy me - it
may require a fair bit of work; it might, for example, require us to
make random access to a gzipped capture efficient, which I think might
be doable, given that
1) gzipped files appear to consist of independently-compressed
chunks, which I think may start on byte boundaries in both
the compressed and uncompressed data streams
and
2) we only randomly access frames that we've already seen in a
sequential pass through the file, so we know where in the
streams the chunk containing the beginning of the frame is).
> Guy has submitted the changes to the GTK+ folks, but they have not integrated
> his patches into GTK+. By a note I read on the mailing list, they seem to want
> to wait until GTK+-1.4 is out so they can use the GQueue container, which
> apparently is a GList that knows where its tail is.
I think they also want to replace the CList and CTree with a new widget
which may provide at least some of the capabilities I want (I'd like to
see it provide them all).
