[Jeff Foster <jfoste@xxxxxxxxxxxx>]

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

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


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

You're right, Window is the wrong word; should be 'hex display' or
something along that line.

.....

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

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.

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.


> > 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()".
> 

Is the packet_unselect_list_cb routine doing the notebook tab 
destruction? I prefer this to keep all gui code in the gtk
directory.

> 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....)

No idea. It will probably look different, I think we will get a 'blank'
(gray?) window instead of the 'empty' (white) panel that a text widget
would have.  



Jeff Foster
jfoste@xxxxxxxxxxxx