>
> From: Guy Harris [mailto:guy@xxxxxxxxxx]
> Sent: Tuesday, February 27, 2001 1:00 PM
>
> > > The byte view window is changed to a gtk_notebook and the individual
> > > hex dump windows are tabbed entries in the notebook. The dissector
> > > that needs to create a second (third,fourth,..) view will call a
> function
> > > add_byte_tab with the tab label, data pointer, and data length.
> >
> > Hmm.
> >
> > Are the byte views always associated with a "top-level" tvbuff holding the
> > data?
>
> No. The code I have creates a new tvbuffer to pass on to sub-dissectors.
> It's up to the code jockey, but I can't think of an example where the
> new byte view would use the "top-level" tvbuff
Would, or wouldn't?
I'd expect that, if protocol X contained encrypted or compressed data,
and its dissector decrypted or uncompressed the data to be handed to a
subdissector, it would *have* to create a new tvbuff for it, so that the
subdissector had something on which to work.
> > If so, you might want to add a "const char *name" field to "struct
> > tvbuff", and make "tvb_new_real_data()", "tvb_set_real_data()", and
> > "tvb_new_composite()" take an additional "const char *name" argument, to
> > set the name of the tvbuff; subset tvbuffs would inherit the name from
> > the parent tvbuff.
>
> The current gui code doesn't know about tvbuffers, do we really
> want to go this way?
The current dissector code doesn't know about hex display notebook
pages; do we really want to go that way?
I.e., this is a case where the dissectors have to tell the UI code
*somehow* that there's a new batch of hex data to be
displayed/printed/whatever. I don't personally see adding a name to a
tvbuff as being any less clean than having the dissectors say "OK, I
need a new notebook page" - and, as noted, it's not really doing that,
as Tethereal doesn't have notebook pages; what it's really doing is
associating a name with a chunk of data.
> Hmmm, it does eliminate the cfile.pd references
> in the code.... but it adds display information into the tvbuffer
> which has been a clean structure dedicated to handling data.
The preferences data structures, for example, have display information;
I suspect I'll be adding display names to dissector tables as well, for
future UI purposes.
Heck, a "header_field_info" structure has all sorts of display
information, such as the "name" field (which shows up in the protocol
tree display and printout) and the "blurb" field. Until we completely
eliminate all UI code from Ethereal and Tethereal, stuff that's "only
there for handling data" is going to have names to be shown to the user
- and I might consider it cleaner to keep the names for the user as part
of the data structures than to have them as separate objects.
> What if the coder creates a new top-level tvbuff that doesn't require
> a hex view? I wish I could think of an example here. But I can't so
> this may not apply.
They could pass in a null pointer, I guess - but I strongly suspect that
there won't be any case where it wouldn't require a hex view.
> I think I see a problem with you scheme, or may be a problem in
> how I coded my dissector. After I create the new tvbuff and call
> the sub-dissectors, I free the tvbuffer. I can't do this in your
> scheme. We have to create a list of top-level tvbuffers, for
> clean-up in the epan_dissect_free routine.
Yes, but that's arguably cleaner than freeing the tvbuffs yourself in
the dissector.
> > The notebook tabs would be destroyed; the tvbuffs would be freed by
> > "epan_dissect_free()", which is called by "unselect_packet()".
>
> Is the packet_unselect_list_cb routine doing the notebook tab
> destruction? I prefer this to keep all gui code in the gtk
> directory.
Then "packet_unselect_list_cb()" would be the right place to do that.
