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 _______________________________________________ Ethereal-dev mailing list [EMAIL PROTECTED] http://www.ethereal.com/mailman/listinfo/ethereal-dev
