Ethereal-dev: Re: [ethereal-dev] Filter Colorization patch(es)

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Jeff Jahr <jjahr@xxxxxxxxxxxxxx>
Date: Tue, 24 Aug 1999 11:51:44 -0700 (PDT)

On Tue, 24 Aug 1999, John McDermott wrote:

> I'm glad you like it!  If you'd let me know what filter you tried, I'll
> see if I can reproduce the crash.

I forget what filter i tried, but here is a bug... if you hit 'new' in the
colorize window, it immediately adds a bogus filter to the list.  If you
try and 'match selected' with the new filter window still open (i.e.,
before it has a chance to sanity check itself) ethereal segfaults at
dfilter.c:288.  Why did I do it in the first place?  I needed to have
'match selected' print out the proper filter string down at the bottom of
the decode window so that I could copy it into my color filter.  That
brings up a useful mod... how about a button in the colorizer for copying
the current dispaly filter into a new color filter?  ;')

> > I think the 'add color to protocols' window could be improved by moving
> > the model from a single list of all configured filters that can be applied
> > or not via the setting of the Display->Colorize... option, to a dual list
> > of 'available filters' and 'applied filters' and just always enable the
> > colorization.  If the window was set up that way, we could include a
> > pre-configured list of 'useful' (or 'example', if you prefer) filters that
> > the user could pick and choose from at runtime, or edit/add and save.
> > The way it is right now, I forsee a lot of Creating, Deleteing and
> > Recreating of complex color filters depending on what it is im trying to
> > highlight at the moment.
> 
> One thing that you might try is that I did put in an option to allow
> compilation of some pre-defined filters.  I am also considering adding a
> prototype .ethereal/colorfilers with a big list to use as a starting
> point.  How does that sound?

Im cool with compiled in filters as long as the filters in the user's
filterfile will override the defaults.  Yeah, it sounds great.

What I see happening is that I will have a few cliche'd filter sets that I
will always want to have laying around, but not always all applied at the
same time.  For example, It will be very handy for me to have a set of
color filters that highlights packets with pppoe encapsulation.  At other
times, I need to monitor for spurious broadcast packets.  I'd like to be
able to say, 'quickly install the 6 filters that I use to color pppoe' or
when I switch tasks, 'load the set of filters that colors different
broadcast packets in shades of red, except for ARP protocol which should
be blue.' The problem could be solved if we had a global list of all known
filters, plus a way to load and save sets of them for application during
different tasks.

Right now with the one list and no load button, color is an all-or-nothing
kind of thing.

-jsj