["Ulf Lamping" <ulf.lamping@xxxxxx>]

Guy Harris <guy@xxxxxxxxxxxx> schrieb am 21.10.03 21:54:58:
> 
> 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.

Ok, changed to "Time display format" in the doc.

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

Sounds much better, changed in the doc. But where else does this apply? I think only at this point, or do I miss something out?

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

Hmm. I think the toplevel items should be sorted and named by the things that the user can do with, I tried to sort it that way. As I'm not using this things often, I need some help on this topic. 
Remember: The user is usually not interested, how things are implemented, so I think calling this toplevel item "Taps" or such will not be very useful.

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

Funny thing! Because of this, we have to implement internationalization. Maybe this is a bit oversized ;-)

I will keep calling it "Analyse". As my native language is german, I don't mind the difference.

> ...
> so perhaps it should be View->Reload instead.

Ok, changed from "Refresh" to "Reload" in the doc.

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

Ok, So the place I've choosen seems to be correct.

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

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

> > "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 :-(

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

Since now, I don't get negative responses on this.

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

Well, I have expected something like that. So it's a thing for the future, and not for now.

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

Hmmm. That sounds like a lot of work :-( 
As I have stated in the mail to Olivier, this *is* a topic for all the users I know. For a first step, I will add some text to the online help (maybe copied from the user's guide), that will explain the filter usage of both filters. But don't expect this in the next days.

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

Proposal: I could implement the "Do you want to save" dialog for the capture file I have mentioned, as this seems to be ok. We could add the other dialogs where appropriate later. 

What I have forgotten to write about the capture file "Do you want to save" dialog: The same applies of course not only for program quit, but also everytime the user would otherwise delete an unsaved capture file, at: "File/Close" and "Capture/Start...".


I will try to update the doc today, and will send a new version of it to the dev-list.

Thanks for your quick responses (this time and also before),

Regards, ULFL
______________________________________________________________________________
Horoskop, Comics, VIPs, Wetter, Sport und Lotto im WEB.DE Screensaver1.2
Kostenlos downloaden: http://screensaver.web.de/?mc=021110