I've been hacking on the proto_tree tonight; I fixed the bug
where the tree was being drawn for the wrong frame because
the clist row was being used as an index into the cf->plist
list of frame_data structs. I did this by adding an
array of pointers to the frame_data structs for those frames
that passed through the display filter. I just now read
Guy's suggestion; yes, if we can tuck away the frame_data
pointer in the clist, that would be great!
Also, I implemented Ashok's suggestion of a generic,
non-filterable, text-only (as opposed to containing
data), field. Guy had mentioned this to me too, but I was
too dense in figuring out how to implement it easily.
I have added a new proto_() function:
proto_tree_add_text()
And amazingly enough, it has the same arguments as the
old-style proto_tree_add_item(). So, when adding registered
fields and protocols to the tree, we use a
proto_tree_add_item*() function, and when it's just
non-filterable text, we use proto_tree_add_text().
(internally, proto_tree_add_text uses its own registered
protocol/field, hf_text_only)
I went through all the dissectors and 1) changed the way
new subtrees are allocated, in accordance with the new
method, using one function call instead of two, and 2)
simply renamed all the old proto_tree_add_item()
calls to proto_tree_add_text().
So now ethereal is not crippled; all the decoded information
will be on the GUI tree; it's just not all filterable yet.
"Match selected" and "TCP Follow" are crippled, however.
In this new patch, I make wiretap mandatory. It is used to
read all file formats, including libpcap. And I removed
the attempt at a BPF compiler from wiretap, makeing wiretap
a lot smaller. So, ethereal becomes:
ethreal + gtk+-1.2.x + libpcap + wiretap
You can download the tarball at
http://www.xiexie.org/ethereal/ethereal-proto-990703.tar.gz
--gilbert
