Ethereal-dev: Re: [Ethereal-dev] Deactivate "Apply" button if the display filteris not valid?
Olivier Biot wrote:
From: Ulf Lamping
| 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?
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.
| 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.
Well, if we apply the same display filter again, that's no problem. I
have changed the filter engine some days (weeks?) ago,
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
