Olivier Biot wrote:
> |From: Ulf Lamping
> |
> |From: Olivier Biot
> |
> |> |From: Ulf Lamping
>
> [snip]
>
> |> |Selected -> Selected
> |> |Not Selected -> Not Selected
> |> |And Selected -> ... and Selected
> |> |Or Selected -> ... or Selected
> |> |And Not Selected -> ... and not Selected
> |> |Or Not Selected -> ... or not Selected
> |>
> |> I'd really want to have the "is present" test to be
> |> available too (as 1st item).
> |
> |Agreed, "is present" would be nice (but not as the 1st
> |element, because Selected is the most commonly used item,
> |at least for me).
>
> Now that I am thinking a little more about this, I'd like
> to have the following possibilities:
>
> Operator | is present | has the selected value
> ---------+------------+------------------------
> (N/A) | x | x
> not | x | x
> ...............................................
> and | x | x
> or | x | x
> and not | x | x
> or not | x | x
>
> The first items replace the current filter expression,
> while the last 4 rows append to the existing filter.
>
> Maybe a new dialog is more suitable than a nested
> 2-level menu for offering the end-user the possible
> options. That would mean trading use speed for clarity.
I would not like to have to use a dialogue for the most normal case I'm
using (Prepare/Selected).
I normally use some hand editing if I want another variant.
>
> |> Maybe we can expand the context menu by replacing
> |> "Selected" with the field
> |> name and value, if the selection is a field or protocol?
> |
> |I'm currently looking exactly how to do this (didn't found an
> |easy way until now), as this would "boost" intuitivity IMHO.
>
> How about the PITEM_FINFO() accessor macro and for example the
> code for proto_item_append_string() in epan/proto.c?
>
> |> |Explanation:
> |> |I want to distinguish "visually" between the subitems that
> |> |replaces the filter and the ones that will append to the
> |> |existing string in the filter text entry.
> |> |Question: Any better term for ...?
> |>
> |> You may replace "..." with "Current filter";
> |
> |That's a bit too long, I think.
>
> Unless we generate a custom dialog for this functionality :)
>
> |> if no filter is available yet,
> |> then the and/or options must be grayed out.
> |
> |Yes, that's related to fill in the currently selected "thing"
> |into the menuitems label (currently I just don't know how, but
> |looking at it).
>
> Isn't that related to the fact whether there currently is a
> display filter or not, so it should be somewhere in the cfile
> global variable.
It could also be nice to be able to make it possible to select between
several different
filters in some cases.
frame[132:4] == 56:69:61:3a
ip[116:4] == 56:69:61:3a
udp[96:4] == 56:69:61:3a
sip[88:4] == 56:69:61:3a
But I don't know how difficult it would be to implement something like that.
