Ethereal-dev: Re: [Ethereal-dev] Menu Usability Changes

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

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Wed, 22 Oct 2003 11:59:23 -0700

On Oct 22, 2003, at 1:51 AM, Ulf Lamping wrote:

As noted above, the Tools->Statistics menu is constructed by individual
taps registering menu items.  This means that we'd need to change the
API for taps to control the ordering of items in the 'Statistics" menu.


As mentioned above, I'm not sure about the arrangement of this two toplevel items.

I'm not sure what it should be, either - but if taps go under more than one top-level menu, we'd have to change the API, even if the only change is to have the menu path supplied when registering the tap be a path rooted at the menu bar (e.g., register as "Statistics/XYZP" for a tap that gives statistics for the XYZ protocol or "Analyse/TCP Stream" for a tapified version of "TCP Stream Analysis").

That parenthetical note raises another question (which somebody else might have raised) - should Analyse->TCP Stream Analysis be just Analyse->TCP Stream?

"Decode As" / "User Specified Decode" dialogs

"Decode As" and "User Specified Decode" may access the same table, but
"Decode As" isn't a general editor of the decode table - it's intended
to let you control decoding of packets in the same category as the
currently selected packet.

So is it really doing a different thing? I'm still confused :-(

It's different in that it'd be useful to have

1) something that allows you to add entries to the list of dissector table/selector value/dissector bindings, remove entries from that list, change entries from that list, and see the list, unrelated to a particular packet;

and

2) something to let you affect the decoding of packets "like" the current packet, e.g. packets with the same link-layer type, packets with the same network-layer protocol identifier, packets with with the same {source,destination} transport-layer selector (port #, etc.), packets in the same conversation, etc..

The first would be like an editable "User Specified Decode", although that raises the question of whether it should let you remove or change a *default* binding (I'd say "yes", although it should perhaps distinguish between default bindings and user-specified bindings, and perhaps let you revert to the default bindings for a particular dissector table - if so, it'd be more than just "User Specified" decodes).

The second would be like "Decode As". Perhaps different names should be chosen for them to make the distinction clearer.