Jeff Jahr wrote:
>
> 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 will look into that. I don't think that would be too hard. Might it
be a good idea to have the default filter be the display filter (if one
exists) instead of the string "filter"? That would be fairly simple.
>
> > > 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.
They do. I really think that I may just provide a list of defaults in
the user's file.
>
> 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.
I agree.
>
> Right now with the one list and no load button, color is an all-or-nothing
> kind of thing.
Yeah. I could add 'Clear all' and 'Load from file" buttons, I suppose.
>
> -jsj
--john
--
John McDermott jjm@xxxxxxxxxx
Writer and Computer Consultant
J-K International, Ltd.
+1 505/377-6293 - V
+1 505/377-6313 - F
