["Greg Morris" <gmorris@xxxxxxxxxx>]

Color filters are a great way for new users to be able to quickly go
through a trace to locate errors. I have a set of color filters that I
distribute to my users that flags retransmisssion, NCP, SMB, SRVLOC,
etc... error return values as Red. This way the user can quickly browse
through the summary and identify any errors. I know that a wish list
item to have intellegence built into Ethereal to flag errors has not
been completed but color filters help to provide this mechanism. It
doesn't trap for problems like an intellegent algorythm might but it
does provide as a useful tool when quickly analyzing a trace. In fact it
does a much better job then NAI's Sniffer Pro expert.

The remaining color filters that I do is based on protocol so I color
TCP packets one color and DNS packets another. Much the way that Sniffer
does so that it gives the user much the same look and feel. I think we
just need to come to an agreement as to what colors fit for what
protocols. 

Display and Capture filters - Yes these are unique to your environment
but to a new user or one that is unfamiliar with the syntax, It is nice
to be able to provide sample filters. For example - ether host
xx:xx:xx:xx:xx:xx with the name of Capture by MAC Address. These can be
basically used as templates by users to quickly configure a filter
instead of having to call someone or look it up. I used to get many
calls from my end users asking how to create a filter. Since providing
the sample filters, I haven't received a single call.

All in all, everything but the preference file itself should be
provided if at all possible. It makes Ethereal user friendly. Sure the
expert Ethereal user will not need or might not even desire to have
them, but as Ethereal becomes more and more popular these will become a
valuable asset. Anything we can do to help users use the tool will only
make the tool that much more popular.

My 2 cents,
Greg

>>> guy@xxxxxxxxxxxx 2/4/2004 12:43:03 PM >>>

On Feb 4, 2004, at 2:16 AM, Ulf Lamping wrote:

> Do we want to add some default configuration files (cfilters, 
> colorfilters, dfilters, preferences)?

Preferences:

    The only reason I can see for a default preferences file would be
if 
the values to which the preferences are initialized in the code weren't

appropriate...

    ...in which case the right way to fix that would be to initialize 
them, in the code, to the right values.  I don't see such a file as 
being useful as a guide to users - most users would probably edit their

preferences through the GUI, anyway.

Color filters:

    At least for color filters, there are both user and system-wide
color 
filters; would a default color filters file be a user file or a 
system-wide file?

    And what colors and filter expressions would it have?  Is there a
set 
that would be close enough to what most people would want that it'd 
even make *sense* to have a default color filter file?  Or are color 
filters enough of a personal thing that a default color filter file 
wouldn't make sense?

Capture and display filters:

    Ethereal currently has no notion of a system-wide capture or
display 
filter file.  Should we add a system-wide file for them, too, and 
supply a set of useful filters in them?

> I would tend to say yes. But as this topic isn't win32 specific, we 
> should do this
> for all platforms, not only win32. Even if other platforms are not 
> able to install these files (just don't know if this is possible), 
> there should be a basic set of configuration files at least available

> somewhere in CVS.

Whether other platforms could install them depends on whether they're 
system-wide files or not.  System-wide files can be installed - on 
UNIXes, they're installed in the same directory in which other data 
files for Ethereal are installed.  Per-user files, however, are mo
re difficult - UNIX package installers, probably for reasons having to

do with UNIX's multi-user origins, tend to install stuff system-wide 
rather than having the notion of a user on whose behalf installation is

being done.

> My personal believe to the whole thing, when reflecting some mailings

> in the past days is:
> - require to use a current NSIS installer version (e.g.: 2.0 RC 3)

I'll leave that one up to the maker of the installer (Gerald) to 
decide.  If he says "yes", then:

> - use the modern NSIS user interface (MODERN_UI)

That's probably a good idea, but I don't know enough about what 
disadvantages, if any, there are of the modern UI to say 
authoritatively.

> - using the lzma compression algorithm to reduce installer size 
> dramatically

Sounds good.

> - put both Ethereal GTK versions 1 and 2 (together with the DLL's and

> such) into one installer

Would the installer install both of them?

If so, how would the user know which one they should choose?

If not, how would the installer decide which one to use?  (And if it 
finds out from the user, how would the user know which one they should

choose?)

> - put some example config files in CVS and install them with the 
> installer

See above.

_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx 
http://www.ethereal.com/mailman/listinfo/ethereal-dev