[Guy Harris <guy@xxxxxxxxxx>]

> 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?

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 name would be what shows in the tab for the data in that tvbuff.

> This
> function will return an index number for the new byte view. This permits
> the dissector to create a new hex display window and set the data to
> be displayed in the window.

Well, actually, dissectors can't create windows or do any other UI stuff
- the GUI code would be what did that.

> The dissector is responsible for management
> of the secondary data array.  It can NOT be a local variable.

The same would, of course, apply to the data array a dissector attaches
to a new "real" or "composite" tvbuff that it creates.

> A byte view variable is added to the field_info structure so the correct
> hex display window is selected when the protocol display tree item is 
> selected.

It could, in the scheme I describe above, be a "tvbuff_t *". 
"alloc_field_info()" would set that field for you - the dissector
wouldn't even have to know about it, and neither would most of the
routines in "epan/proto.c" ("alloc_field_info()" already takes a
"tvbuff_t *" argument).

> Dirty details -
> 
> 1) The field_info structure changed to add a bv_num. This is an integer 
>    that is used to select which hex window tab to use.

Or, in the scheme described above, a "tvbuff_t *".

We might want a tvbuff routine to find the "top-level" tvbuff of a given
tvbuff:

	if the tvbuff is a real or composite tvbuff, that tvbuff is the
	top-level tvbuff;

	otherwise, it's a subset tvbuff, and the top-level tvbuff of
	that tvbuff is the top-level tvbuff of the tvbuff of which it's
	a subset;

so that, in order to determine which hex window to use for a given
field, you find the top-level tvbuff for the tvbuff referred to by the
"field_info" structure, and look for the hex window for that tvbuff.

> 2) Static integer current_bv_num added to epan/proto.c.  There are two
>    routines set_bv_num and get_bv_num used to access this value.
> 
>    current_bv_num is reset to zero in the epan_dissect_new routine.

Not needed, as far as I can tell, in the scheme I describe above.

> 3) The proto_tree_add_item modified to set the new_fi->bv_num to the
>    current_bv_num value.

Again, not needed.

> 4) The create_byte_view routine modified to create a notebook and 
>    the first tabbed window. The tabs are not displayed at this point.

Same in my scheme.

> 5) A add_byte_view routine added to gtk/proto_draw.c.  This routine
>    will create an additional tabbed window in the byte view notebook 
>    and return the index for this window.  In addition the routine
>    will store the data pointer and data length in the new tab window
>    object.  These are used during the packet_hex_print calls.

We might want some scheme here to enumerate all the top-level tvbuffs
currently in existence, or all the top-level tvbuffs used in the
dissection of the current frame; the GUI code would generate a notebook
tab  for each of those tvbuffs.

> 6) The packet_hex_print routine is modified to accept a data length
>    value.  This is used in place of fd->cap_len in the current routine.

Same in my scheme.

> 7) The tree_view_select_row_cb (gtk/main.c) is changed to select the
>    correct byte view table before calling the packet_hex_print.

Same in my scheme.

> 8) The packet_unselect_list_cb will destroy the secondary byte views.
>    Still working on this...

The notebook tabs would be destroyed; the tvbuffs would be freed by
"epan_dissect_free()", which is called by "unselect_packet()".

You might want to destroy *all* the notebook tabs, so that if there
isn't any packet selected, there aren't any tabs in the notebook, to
indicate that there's no data.  (This presumes that a notebook widget
behaves sanely when no tabs exist....)
>    
> The "packet window" code, will have to perform steps 7 and 8, still
> working on this...

> ToDo -
> 
> 1) How will this affect tethereal?  How will we display the extra byte
>    view data?  
> 
>    I think it can be modified to display the "tab label" and generate
>    the hex dump for each byte view.

Yes, that's what it should do.

> 2) How will this affect printing in ethereal? 

"Printing in Ethereal" is similar to "running Tethereal without the '-w'
flag", so it'd work the same way.