Ethereal-users: Re: [Ethereal-users] Ethereal preferences appear to be broken/ign ored

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxx>
Date: Tue, 15 May 2001 15:09:19 -0700 (PDT)
> I don't pretend to be able to fix this myself,
> but it sure was confusing.  I think that
> the feature/button 'apply' sould mean to put
> it into effect immediately.  'Save' to me means
> preserve this setting for the next time the
> application is run.  I was only displaying a 
> previously captured file.  Nothing was live 
> or needing to be dynamic.  The variables were
> all in memory, and should be able to be 
> displayed quickly.

Well, actually, no, it isn't able to do that, given the way the GTK+
widget that displays the column list works.

That widget has no support for adding new columns, or moving columns
around (it has support for "invisible" columns that could be made
visible, but there'd be both a significant memory overhead and a
significant time overhead for filling in "invisible" columns in case
they're needed, and that wouldn't help if the columns weren't put where
the user ended up wanting them), so Ethereal would have to destroy those
windows and re-create them, which involves re-scanning the capture and
re-building all column values for all packets.

> 
> I appreciate that the change could be performed
> at all.  I just ask for it to be easier.

I'd like it to be easier, too, but it's non-trivial to fix, given the
way the widget that displays the packet list currently works, and, given
that the list of Things People Want From Ethereal seems to grow faster
than the list of People Working On Ethereal (and given that the amount
of Time Available To Work On Ethereal for at least some of us is either
not increasing or perhaps even decreasing at times), it won't
necessarily happen any time soon.

A replacement widget (actually, a modification of the existing widget)
would help this, and help other problems as well (significantly reducing
the memory requirements for large capture files); unfortunately, that
widget requires that, among other things, moving backwards through a
capture file - *even a compressed capture file* - work quickly, and it
doesn't work at all quickly right now if the file is compressed.

I have work-in-progress on the new widget, and an idea of how to make
random access to a compressed capture file faster, but don't have a lot
of time to work on it right now (and don't have an internet connection
at home to use for that, although, with any luck, that will be fixed
shortly).  Neither of those will necessarily happen any time soon.