Biot Olivier wrote:
|From: Guy Harris
|
|On Tue, Feb 10, 2004 at 07:33:52AM +0100, Ulf Lamping wrote:
|> Olivier Biot wrote:
|> >I agree. However: should valid empty filters (such as a
|single space)
|> >be cleared or considered cleared?
|> >
|> If the user wants a single space, he should be able to use it, so I
|> would tend to see this as a non emtpy filter.
|> You will get a lot of difficult questions otherwise: is a tab also a
|> whitespace, do we want to remove this and that too,
|> why is character xyz not removed. This behaviour will be hard to
|> describe for our users.
|
|Note that a display filter containing only white space compiles to a
|null filter program, just as an empty string does.
|
|As such, I see a filter with a single space as an *empty* filter. (I
|also consider the fact that no filter program is generated to be a
|feature, not a bug.)
Hence I conclude that an empty filter (consisting of white space only)
should be considered as cleared (which was my *personal* thought on this
too).
Should we implement this check and the deactivation of the "Apply" button
and stuff, then we can add a short note to the documentation that you can
still fool Ethereal by editing white space to force a full dissection.
Should we want to avoid this, then we need to:
1. Store the last applied display filter *program*
2. Compare the new filter program with the stored one
from step 1 whenever the display filter changes
3. Decide to make "Apply" visible (and to decide that
the display filter may be applied) whenever the
filter programs differ.
Ok, no problem if you tend to "ignore" whitespace changes. I just don't
know how to implement this in
the filter engine.
My optimization was simply to just do nothing, if the filter strings of
the existing filter, and the new filter from the text entry are
exactly the same (used simple strcmp here).
This prevented *replacing* the filter program with a new one, being
exactly the same, which I thought was enough for this topic.
Didn't thought about whitespace when implementing this.
Of course there is a difference comparing the filter strings and the
resulting filter programs, especially for whitespaces and such.
It's something more sophisticated to build a new filter program, and
compare this with the existing one.
This will then ignore differences in whitespace and such.
I'm not saying this would not be the better way, I just didn't get the
idea to do it that way.
Feel free to change things that way.
I could give you a helping hand for the GUI things, as I have more
knowledge on this topic than the filter stuff.
BTW: do we want to change this, before the next release (which should
appear in the next days)?
As this might make things buggy again, it might be a good idea to do
this *after* the next release.
Regards, ULFL