Olivier Biot wrote:
| > 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.
|
| You're presuming that such an agreement would be possible; I don't
know
| that everybody wants the same color filters. (I would, personally,
| uninstall any default color filter file installed on my machine -
color
| filters slow down capture loading, and, shocking as I suspect this
| would be to many Ethereal users from what some users say, *I just
don't
| use color filters at all*.)
I tend to disable color filters when processing large capture files,
and enable them when I am looking at smaller ones. This is not always
true however. But... many novice users only look at smaller captures
for which the impact of alpplying color filters is not that high. As
said in a previous mail, I'd like to have a preference controlling the
color filter usage, so I don't need to rename the color filter file to
obtain the same result. This preference could go in the existing
colors pane (sorry guys, I'm not a Gtk+ programmer and I don't want to
ruin the lay-outs).
I wasn't a GTK programmer some months ago, but I managed to learn it for
some degree ;-)
Ruining the layouts was done quite a while ago, and I tried to put some
things back together.
Thanks, for not going to get me even more work to do :-)))
You talking about disabling the color filters for long capture filters.
Should this be a permanent or temporary setting?
I guess this should be a temporary setting.
This might be automatically detected be the size of the capture file to
be read in.
When a very long capture file is detected (that a specific action will
be take a long time), ask for some additional settings, e.g. disabling
the colorfilters.
| Perhaps if a site or organization wants to package a version of
| Ethereal with a set of color filters useful in their environment,
they
| should do that; I'm not convinced that one can come up with a set of
| color filters useful for everybody, other than, perhaps, a singleton
| set with "mark errors in red" as the only such filter.
Color filters serve a purpose. Depending on the purpose, the color
filter will vary too. Hence my roposal to create a library of
purpose-written color filters (maybe something we can add to the
Ethereal web site). We should do the same for display filters, and
maybe for capture filters too (but here the dependency on the BPF
version is crucial).
| > Display and Capture filters - Yes these are unique to your
environment
|
| I *didn't* make that argument about display and capture filters;
that's
| the one set of configuration files where I *don't* see an issue
(other
| than the lack of system-wide filter files) with supplying a default
| file.
Hmmm... I'm rethinking the need for a global color filter file. The
reason is the purpose of it - there is no single purpose to an
Ethereal user. Some use it to debug protocol implementations, others
to track network problems, others want to know what's going on in
those bits and bytes for educational reasons...
But, I'm not talking about any particular purpose, I'm only talking
about the possibility. It's not about
forcing the user to a purpose he will not have. It's about showing him
the possibility he might want to use.
If he just don't want to use it, that's just fine!
Please,
.............................................................................................
it sounds to me, that when you searching for something or someone don't
want to use colorfilters, you will always find a reason not to.
If you personally dislike colorfilters, that's fine, you will have
reasons for this.
If you have special cases where colorfilters are not appropriate, that's
fine.
BUT: don't hide that possibility to novice users! They might have very
different needs compared to yours and might find colorfilters *very*
useful for their needs,
as this is reported "frequently" to the list.
If that's a performance problem, this should be indicated by some other
mechanisms (dialog box if capture file very long for example), but not
avoided.
It might be a good idea to add some words to the help pages about
performance issues (both for capturing and displaying).
Regards, ULFL