I agree with the suggested name changes, but I still don't think the 
functionality is necessary.
 
The timeline view (in its current form) seems to look very similar to the new 
(Qt only) "packet/color summary scroll bar" to the right of the packet list 
(not sure of its official name).  That needs some level of dissection to 
determine the color of each packet to draw the scrollbar.  I don't believe it 
uses taps, but it did not put any additional requirements/code into dissectors. 
 I would suggest modeling the timeline view after that.  I don't know enough 
about Qt to make more specific suggestions, but if someone provided the classes 
used in the Qt GUI code for the scrollbar, I might be able to copy/paste/hack 
the timeline view to look similar.  The timeline view is certainly a cool 
feature, I just think it needs some architecture work to be submitted.
 
This is an interesting problem because I'm not sure where the "data crunching" 
should really be done (GUI vs dissector).  For statistics dialogs, I think more 
data computation is done in the GUI (taking information from taps).  It doesn't 
appear to me that the dissector does anything with the computation except to 
feed it to the GUI, so I don't think it would be bad if it was moved out of the 
dissector (and remove the need for all of the epan APIs added just for this 
feature).
 
 
-----Original Message-----
From: Guy Harris <[email protected]>
To: Developer support list for Wireshark <[email protected]>
Sent: Fri, Apr 14, 2017 5:13 pm
Subject: Re: [Wireshark-dev] epan_t and capture_file

On Apr 14, 2017, at 2:02 PM, Simon Barber <[email protected]> wrote:

> The timeline needs to know whether every packet includes timing information. 
> If not, the timeline should be hidden. This is only determined after all the 
> packets have been through a first dissection pass.

Then there needs to be a mechanism by which the timeline GUI code can inquire 
whether every packet includes timing information.

The change to allow dissectors to share per-capture data (not "private" data, 
"private" means you *don't* share it, as per Michael Mann's comment) would be a 
mechanism to do that.

For now, just change "private" to "per_capture" in the function and 
variable/field names and to "per-capture" elsewhere, and wait for it to be 
approved.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe

Reply via email to