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
Powered by MHonArc 2.6.10