ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Regarding bug 948 - capture vs preferences

From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Fri, 17 Nov 2006 03:04:57 +0100
Stuart MacDonald wrote:
From: On Behalf Of Ulf Lamping
A slightly different question remains:

Do we need these capture related Preference settings anymore as we have the recent file now?

To preserve the "general & per-capture override" mechanism, yes the
Preference settings are needed.

Obviously
A more "natural" approach to my eyes would be to save the interface settings (and alike) in the recent file ...

Design question; does Wireshark want the "general & per-capture
override" mechanism? Or a simpler, "repeat last capture" mechanism.
Obviously, see below ...
Personally I prefer the "general & per-capture". Usually I want the
same thing as last time, but every once in a while I want something
different, like to capture to ring buffers, or to turn live updating
off. I find the per-capture override very very handy.

That depends widely on the way you are using WS. Some persons I've talked to always uses ring buffer and asked for a preference setting for this - which might annoy you :-)

My personal experience is to have a sequence of things. I want to do ring buffer capture for maybe ten times, then do a "simple capture" for five times, then ...

So for me using the recent settings makes most sense - and this model is also (by far) the easiest to understand for newbies!
Unfortunately, this leaves the questions open how tshark should be working as it's only working with the settings in the Preferences file :-(

It's okay for a different app (even from the same family) to work
differently.
Yes, but losing ALL settings for tshark doesn't sound like a viable option (tshark currently doesn't know about the recent file).
From: On Behalf Of Jaap Keuter
2. Find a way to incorporate the preference changes into the (possibly
already changed) capture dialog.

Interesting. There's a conflict of operation between having the
changed preferences update the per-capture dialog, and the dialog
wanting to use the most recent settings.

Suggestion: have the per-capture load the last settings, but check the
preferences. If the preferences do not match, have an extra button to
update the dialog from the preferences instead.
Making the GUI even more complicated :-(

As a general guideline: Having to add a new GUI element to circumvent problems is a CLEAR indicator of a bad GUI design!

Think about someone new to Wireshark and guess if he will understand the way Wireshark works in this regard.

If you have a clue about usability, you'll guess that a newbie user is just lost in this case. Having two places to adjust settings (with a different "scope") is just a bad usability idea which cries to confuse a user.

Obviously, a change in the regard I've mentioned will force advanced users to change their habits.

Question: Would it really be that annoying to change your habits (changing habits can be annoying - I know) - or will it *really* annoy you in your everyday work in the long run?

Regards, ULFL