From: Ulf LampingIf 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.
| Biot Olivier wrote: | | >Hi List, | > | >Today the display filter is shaded green if valid and red if invalid. Maybe | >we want to activate the "Apply" button only if the display filter is valid. | >We could then still have the shading but maybe controlled with a preference? | | I'm unsure, if there's always an "Apply" button (I'm thinking of the | filter dialogs) where you could do this.
I didn't think about the dialogs in the first place, but that's an interesting track, though :)
| Nonetheless, if there *is* an corresponding apply button, we could do this. | | If you think of the filter toolbar at the bottom, I would also | deactivate the "Clear" button, if the string is already empty.
I agree. However: should valid empty filters (such as a single space)
be cleared or considered cleared?
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.
Well, if we apply the same display filter again, that's no problem. I have changed the filter engine some days (weeks?) ago,| This leads to the next question: do we want to deactivate the "OK" | button on the dialogs too, as this will also do an "Apply"?
I would do it the other way round: deactivate "Apply" if you applied. Ideally we would keep track of the changes, and of whether changes have been applied, hence we e.g. avoid applying a display filter twice because we clicked once "Apply" and then "OK" to close the dialog. The logic should be: 1. No changes ==> gray out "Apply"; "OK" only closes the dialog (as does "Cancel"). 2. Changes ==> If "Apply" then apply the changes, clear the "changes" boolean and see 1. above; if "OK" then apply the changes and close the dialog. If "Cancel" then close the dialog without applying the changes.
By disabling/enabling "Apply" the end-user gets feedback on possible changes introduced by the end-user interacting with the dialog or the control., which is a valuable thing. Especially if it can avoid needless processing of a big capture :)
I think that implementing this is straightforward and that's the most obvious way to do this for Windoze users. Probably for other users too.
that it will just do nothing in this case (making a simple string compare with the existing filter).
I changed this with the same thing in mind as you: don't apply the same filter string for very large capture files again,
if it won't obviously change anything.
So we could apply the filter string when pressing "OK", even if it's unchanged, as this will simply do nothing.
I agree, that we could add the described logic to the "Apply" and "Clear" buttons in the filter toolbar, but as the code is a bit more complicated on this
(e.g. apply the filter string from a dialog box into it), and this is just a "nice to have" feature, I tend to do some other things before this.
Although, I had already something similar on my todo list ...
Regards, ULFL
_______________________________________________ Ethereal-dev mailing list [EMAIL PROTECTED] http://www.ethereal.com/mailman/listinfo/ethereal-dev
