Graeme Lunt wrote:
a) Is it architecturally correct to reference a dissector (packet-ber) from
the gtk\ portion of the tree?
That's what the "Follow TCP stream" feature is also doing, and it seems
to be ok.
b) Would a "link" style (like FT_FRAMENUM) be better than extending the
context menu?
Unsure.
Link style:
+ It would make the information much more "prominent" to the user
- Confuses usage of links in the packet details (hmmm, what will happen
if I press this link? Will it jump to another packet or will it open my
web browser?)
Context menu:
+ Same place as the existing links (filter reference, wiki, ...)
- Hard to know if an entry exists for a specific field without trying
(right click on item - no link, right click on next item - no link, ...)
There is a diff attached for the gtk/ files (packet-ber.[ch] patch not
included).
Comments?
Seems to be the best way to handle this for now. I would think to have a
clean mechanism to set a specific help URL corresponding to a protocol
tree item is the more important part for now.
The display and usage of it can be easily changed later. Some time ago I
tried to add a tiny icon to the protocol tree but it doesn't seem to be
possible with the GTK1 based widget we currently use. So we must help
ourself with some special text output (e.g. the blue underlined link for
the FT_FRAMENUM) or add it to the context menu. Both solutions are not
optimal :-(
I was thinking of something similar for the TCP checksum field to link
users to the checksum offloading page of the user's guide, as you might
have noticed from the list that TCP checksum offloading is frequently
confusing users. Maybe your solution will work for this problem too.
Regards, ULFL