[Guy Harris <guy@xxxxxxxxxxxx>]

In the View menu, I didn't know what "Timebase" meant until I saw the 
table.  I think "Time display format" might be clearer - I'd think of a 
"time base" as a start time, or something such as that.

Should the protocol tree view be called the "Tree View", or would it 
make more sense to refer to it as the "decoded packet" or something 
such as that?  Similarly, should the "Byte View" be the "packet data"?  
(This applies to more than just the menus.)

Many of the items under "Statistics" are taps - i.e., the items listed 
there are the current set, but that set could expand over time.  Will 
all taps necessarily be statistical taps?

On Oct 21, 2003, at 8:21 AM, Ulf Lamping wrote:

> 	 2.  	Should the new toplevel item be called "Analyze" or "Analyse" 
> or like something else?

On the US vs. rest-of-English-speaking-world spelling issue, the 
"correct" answer would be to internationalize the menus.  Given that we 
now have a mechanism for adding "fallback" autoconf macros, we might be 
able to have the configure script check for GNU gettext without 
requiring everybody configuring from CVS to have GNU gettext installed.

Whether Analy{s,z}e is the right term for it is another matter.

> 	 3.  	Menu Item "File/Reload" - "File/Revert" - "View/Refresh"? Which 
> name to choose and where to put? We don't Revert to Saved, as we don't 
> change the file after it is once created, so maybe "View/Refresh" is 
> the best choice.

The File->Reload item really *does* reload the file.  The GNOME HIG 
says of View->Refresh:

	Redraws the current view of the document from local storage. For 
example, in a web browser application, this would redraw the page from 
the browser page cache.

	If you want to check if the actual content has changed before 
refreshing the view, for example, checking a web page on a web server, 
label this item Reload rather than Refresh. If your application 
requires both Reload and Refresh, use Shift-Ctrl-R as the shortcut for 
Reload.

so perhaps it should be View->Reload instead.

> 	 5.  	What does the "Go To Corresponding Frame" item do? And where to 
> put it into?

"Go To Corresponding Frame" is active if the current protocol tree item 
is a frame number - it does a "go to frame" to the frame in question.

> 	 6.  	What is the right sequence of the "Statistics" items? Should be 
> going from general to more specific things.

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.

> "Decode As" / "User Specified Decode" dialogs
>
> There shouldn't be two menu items to trigger almost the same 
> functionality. This is very confusing for a normal user.
> One solution could be to build something similar to the colorize 
> display dialog. You will see an overview of the current filters when 
> triggering this dialog by menu or toolbar. From there, you can push 
> some buttons to add/remove rules to the current decodes and such.

"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.

> "Print" dialog
>
> Currently, the user can print the current frame (without any Ethereal 
> specific dialogbox), or all (marked) frames in the capture file. This 
> is confusing when using the toolbar icon, as you don't know what will 
> be done before pressing the icon.
>
> IMHO it s better to build a dialog, where the user selects which 
> frames he/she would like to print (using radio buttons):

I don't personally have a problem with getting rid of "Print Packet", 
and just leaving "Print".  I don't know whether others would, however.

> 	 3.  	The common menuitems "Page Setup" and "Print Preview" should be 
> implemented. Is this possible in GTK anyway, and how expensive is it? 
> Any experience on this?

"Page Setup" and "Print Preview" could be implemented in GTK+; however, 
all that you'd implement would be the dialog.  The hard part of both of 
them would be in Ethereal's printing code.  GTK+ itself doesn't offer a 
printing infrastructure; various desktop environments do.

> Capture vs. Display Filters
> One of the biggest issues to solve in a usability perspective is the 
> "differences" in capture and display filters. It is really odd for new 
> users to learn two different filter "languages". For example: The 
> online help on capture filters is telling you: "see manual page of 
> tcpdump", which is difficult on a usual win32 machine :-(.
>
> A "better than nothing" solution (and quick to implement) would be to 
> include the text from the user's guide into the online help fields, 
> for the capture and display filters.
>
> But of course, the clean solution would be to have just one filter 
> language, presumably the display filter syntax, and derive capture 
> filters from it. The Win32 specific Ethereal GUI 
> "Packetyzer"http://www.packetyzer.comseems to be doing just that. We 
> could have a look, how they solved this topic.

I don't have Packetyzer installed at work (it won't run on Mac OS X, 
and I don't have Virtual PC installed), so I don't know what they do 
with capture filters.  It would not be possible to implement capture 
filters with the full functionality of display filters except as "read 
filters" - which means you have to do a *full dissection* of every 
packet in order to see whether it matches; that might be prohibitively 
expensive in some cases, so that's not acceptable as the *only* capture 
filter mechanism.

However, it *might* be possible to translate a filter syntax similar to 
a small subset of the display filter syntax into the libpcap capture 
filter syntax; one problem is that the set of capture filter operations 
differs from libpcap release to libpcap release, so it'd have to either

	1) figure out, somehow, what filters are acceptable (it might be 
possible to test for particular filter operations by supplying empty 
capture files of particular link-layer types, opening those, and trying 
to compile a filter expression)

or

	2) whenever possible, avoid using operators not supported in older 
libpcaps

or

	3) a combination of those.

> When Closing Ethereal, all things not saved are simply discarded. Your 
> unsaved capture file and all unsaved settings are gone. This is not 
> the way it should be.

The preferences settings issue is a consequence of some preference 
settings (at least the protocol ones) being, at times, per-capture-file 
rather than global.  If we could resolve that issue (e.g., by having 
the saved preferences be an editable set of *default* settings, and 
have a separate item for changing settings for the *current* capture 
file), that might let us automatically save preferences (default 
settings).

However, that raises the question of what the effect should be if you 
change a default setting - should it override the current setting?

> For "Capture Filters", "Display Filters" and "Color Filters", 
> something similar to the Preferences file should be done.

"Capture Filters" and "Display Filters" are just lists of the filters 
available; they're not per-capture; therefore, it might be reasonable 
just to forcibly save them whenever they're changed.  (They might be 
per-profile, but that's another matter; I'd expect that there'd be a 
"current profile" setting, and what you'd be editing would be the 
current profile's list.)

"Color Filters", however, might be set on a per-capture basis.