Guy Harris wrote:
On Mon, Jan 19, 2004 at 01:53:14AM +0100, Ulf Lamping wrote:
The state of the checkboxes will be saved at program quit in the recent
file (and of course reloaded when starting again ;-).
Should we store the window geometry in the "recent" file, rather than in
the preferences file as we do now?
I think so.
We should probably also save the column widths there as well.
And lot's of other GUI widths/heights (e.g. the sizes from the filter
dialogs) as well...
But I'm now just proud getting the "View->Show" things to work :-)
I will add the settings from the "View->Options" dialog in a similar
way,
Well, currently there are in View->Options:
the format used for command-line-specified time stamps;
whether we do automatic scrolling in live captures;
which forms of name resolution are enabled.
The format for command-line-specified (which is probably not a good
name, as it can be specified on the command line with "-t" *OR* in the
GUI from View->Options) time stamps is arguably a View item, as updating
it changes the display. It's perhaps a little ugly that you can both
have "command-line-specified" time columns and explicitly specified time
columns; perhaps the ultimate fix is to
1) make column settings take effect immediately rather than
requiring a restart (which is a bit ugly, as you would have
to delete the column view widget and reconstruct it, unless
we enhance EthClist to support adding columns on the fly and
either make EthClist work on GTK+ 2.x or go for the TreeView
widget in GTK+ 2.x);
2) have a command-line flag for Ethereal and Tethereal to let
the columns to be displayed be set;
although that does mean tht it's a bit uglier to specify the time stamp
format.
As I'm currently implementing the time format things, this is a bit
conflicting.
We have
a.) command-line specified and
b.) settings from the recent file
Don't be sure how this should work then.
As we now have available this as a GUI setting, do we need this as
command line parameter at all?
The "Automatic scrolling in live capture" setting is also arguably a View
item.
This is duplicated in "Edit->Preferences->Capture" page and in
"Capture->Start" dialog. I'm unsure, what the correct behaviour should be.
The name resolution items, however, don't affect the display, at least
not currently - it'd be nice if they could, i.e. turning it on causes
columns and packet detail to show resolved names if possible.
What are they doing anyway? I'm confused about the name resolution in
general and to what they will take effect.
These are the places where the name resolution fields are "available":
File->Open
Edit->Preferences->Name resolution
View->Options
Capture->Start
I'm really confused "what will happen when"!
Any comments?
"Filter Toolbar" and "Status Bar" were a bit confusing, although this is
perhaps a consequence of the fact that, at the bottom of the screen, we
have one row with two widgets.
Of course, if Ethereal were an Aqua application, the filter stuff would
be at the top of the window, like other "Search" widgets (which are
really more like "Filter" widgets, at least in Safari, Mail, and
Preview), rather than on the status line, but....
If Ethereal would be *any* other application, the filter toolbar would
be at the top of the window, just where it belongs ;-)
IMHO the filter toolbar in the statusbar is very odd in a usability
point of view. This results in:
a.) having less space for additional statusbar information. I would like
to have some more general information about the
current capture file in the statusbar (e.g. packets: 230 captured / 10
displayed) or such.
b.) moving the mouse pointer a lot up and down, when using menu / main
toolbar / filter toolbar things.
I would strongly suggest to put the filter toolbar up, just below the
main toolbar.
When I remember correctly, I have made this suggestion quite a while ago
and someone (don't remember who) was complaining
that this would result in even less space on his main screen.
I would really like to find a good solution for this topic, as this is
really looking odd.
Regards, ULFL