On Wed, Jul 26, 2000 at 09:40:10AM -0500, Gilbert Ramirez wrote:
> You're right, it is a poor situation. We could add another column to the
> tree view and show the field name for each item that has one. This second
> column could be shown or hidden by the user.
I suppose, although enabling that column takes more real estate.
> Also, the field name could be shown in the menu that comes up with
> a right-click on the item.
...or there could be a "jam the name for this field into the filter"
menu item; select that item, and the name of the field gets inserted
into the filter text entry box at the current insertion point, just as
if you'd typed it.
A GUI for constructing filters might also be useful - being able to get
the names of fields that *are* in the current protocol tree is all very
well and good, but that doesn't help if the field you want to filter on
*isn't* there.
The Network Monitor GUI lets you construct an expression tree; to create
a node for a single match operation, there's a tabbed notebook with
items for matching addresses, protocols, or "properties" (i.e., fields).
(I suspect that address and protocol matching may not build NetMon's
equivalent of a protocol tree, as an expression with no field matches
seems to run through a large file faster than one with field matches.)
The notebook pane for field matches has a scrolling tree view, with the
top-level nodes being for protocols; clicking on the "+" for a protocol
opens up under it a list of fields in that protocol - we'd presumably
use "name", in the "header_field_info" structure, there, and could, if
there's a blurb, allow that to be seen (e.g., as a tooltip).
Selecting a field causes the pane to show a list of operations you can
perform (such as "contains", i.e. "does this protocol tree contain one
of these, regardless of its value?", and the types of comparisons
allowed) and to provide a text box into which the value with which it
should be compared can be typed.
