I am afraid that adding this to Ethereal today will require serious
work and probably we'll need *ugh* global variables to implement this,
since I only see filter_te_syntax_check_cb() in gtk/filter_prefs.c as
entry point. Actually, that seems to be the place where the display
filter is checked for validity and the color of the widget updated.
This is implemented in a "stateless" manner today, and I don't know if
the call-back allows for state since there's only the GtkWidget
pointer as parameter...
If we consider an empty display filter as valid, then I suggest we
only keep 2 "color states": red for error and green for OK (inclusive
the empty display filter), so we can get rid of the white. Or we can
choose to only flag invalid text entries with a red background and
leave the other valid or empty text entries white.
I however have no clue today where in the code we should add the new
logic as to me GTK code is some sort of spaghetti with lots of knots
:)
----- Original Message -----
From: Guy Harris
|
| On Feb 10, 2004, at 9:51 AM, Ulf Lamping wrote:
|
| > Ok, no problem if you tend to "ignore" whitespace changes. I just
| > don't know how to implement this in the filter engine.
|
| Ignoring whitespace changes in arbitrary filters is more work than
| ignoring filters that contain only white space; I think Olivier was
| talking about the latter.
Correct.
| You can tell whether a filter was empty by checking whether
| "dfilter_compile()" supplied a non-null "dfilter_t" pointer - if the
| pointer it supplied was null, the filter was empty.
You'll want to add a method
gboolean dfilter_equal(dfilter_t **dfp_a, dfilter_t **dfp_b)
to epan/dfilter.[ch] which would compare the byte code of both
compiled display filters and return true if both programs are
identical.
| Note that "filter_packets()" will, if the filter is empty, set
| "cf->dfilter" to null - even if it's "empty" because it's a non-null
| string that contains nothing but white space, so the "Clear" button
| should be turned off if "cf->dfilter" is null.
|
| That would implement "deactivate the clear button if the string is
| already empty", and would consider, for example, a single space as
an
| empty string.
|
| Note that you can't type a tab into the "Filter:" text box, as Tab
| means "go to the next control that can have the input focus". (You
can
| get a tab into that box by manually putting tabs into filter
| expressions in your dfilter file - but the tabs display strangely,
e.g.
| as a square box, and editing the field doesn't seem to work very
well.)
|
| You can type spaces in there - but you can't always tell the spaces
are
| there, especially if they're at the end of the string, or if the
string
| is *all* spaces.
|
| As such, I don't see the user being bothered by us treating all
| white-space-only filters as empty - they'd probably be more
surprised
| by a filter with a space in it being treated *differently* from a
| filter with nothing in it, as you can't easily tell the difference
| between them (you can't tell by looking at the field unless you
notice
| that the typing cursor isn't at the left-hand edge of the field).
I agree 100%.
Regards,
Olivier