ronnie sahlberg wrote:
>So I would suggest something like this for the checksum field :
>
>Make Checksum an expansion
> - Checksum 0x1234 (correct)
> [boolean flag field]
>
>
This sounds like a very good idea to me. So it should look something like:
- Checksum 0x1234 [correct]
[TCP Checksum is good: True]
...
The "baseline" could be left as it currently is (please note that I've changed the brackets from () to [] yesterday), the currently hidden field(s?) will become a subtree.
>Let the boolean field under checksum be a GENERATED field and let it
>be one out of these four :
> tcp.checksum.good [TCP Checksum is good]
> tcp.checksum.bad [TCP Checksum is wrong]
> tcp.checksum.disabled [TCP checksum checking is disabled in
>preferences and not checked]
> tcp.checksum.short_packet [TCP checksum is not checked since the
>packet is short]
>
>
I think we should show all of these fields, so the user will get a quick
idea which fields are possible. The values have to be set according to
the check done (or not set if no check is done).
If we hide the ones currently not "valuable" (e.g. hide the bad field if
checksum is good), we have the same problem than before. How do you know
the field name of the bad field if you want to filter on that. Another
advantage is, that the user will get an idea of the possible results the
check could return. I didn't know that the checksum check could return
short_packet until I've looked into the source code.
That's the same usability logic that also applies to controls: don't
hide/show fields depending on other things. In general, this makes the
UI more complicated, see
http://developer.gnome.org/projects/gup/hig/1.0/controls.html#controls-sensitivity
I might add a new feature for fields currently not appropriate
PROTO_ITEM_SET_DISABLED, e.g. make the font "grey out" for
good/bad/short_packet if the check is disabled.
>In the same way I think IP SRV and IP DST should be an expansion and show
>the hidden field ip.addr as a generated field inside that expansion.
>
>
>
And some others as well, like eth.addr, tcp.port and all other
"combined" fields.
Hmmm, after thinking about it, the same applies to absolute vs. relative
TCP sequence numbers, name resolution and all that wonderful automatic
stuff that's hard to understand for a newbie. I've often had to explain
these fields (to myself and others). An expansion with the detailed
information might be very helpful in all these cases and will make
things far better understandable :-)
>
>This makes it possible to see and learn about these useful fields by
>just looking at real packets in the decode pane.
>
>
That's exactly what I had in mind.
Regards, ULFL