[Biot Olivier <Olivier.Biot@xxxxxxxxxxx>]

| -----Original Message-----
| From: Guy Harris

[snip]

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

Agreed. We are used to give thoose panes a shorthand name, but it is often
counterintuitive for new *users* which are our target audience anyway :)
I'm in favor of "Packet list", "Packet Dissection" and "Packet Data" for
packet view, tree view and byte view.

| 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?

Here too, I would generate categories of taps. Eich tap should register
under a given category. This probably means that we'll have to duplicate
some existing GUI registering code.

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

Mmh... This is interesting!

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

Shouldn't we get rid of it in the menu, and use a context menu (right-click
in the "tree view")?

[snip]

| > 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?

In most of the applications I know, global settings and ad-hoc settings
partially overlap. In the cases where they overlap, an ad-hoc preference
almost always overrules a global preference. In non-overlapping cases, it's
the set value anyway :)

Regards,

Olivier