Yes I meant "UI code of some sort". You know, in case someone submits a Bugzilla ticket for wanting "timeline view in TShark". Then I guess the data computation could be refactored to the ui directory over the qt one.
I mostly wanted to show that not all data computation needs to be done in a dissector and that we need additional APIs to expose that data. While I've tried to move a lot of "protocol specific knowledge" out of the UI, this particular feature (at least at the moment) is very tied to a specific dissector. Otherwise just expanding the "packet/color summary scroll bar" might be an option.
-----Original Message-----
From: Guy Harris <guy@xxxxxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Fri, Apr 14, 2017 7:32 pm
Subject: Re: [Wireshark-dev] epan_t and capture_file
On Apr 14, 2017, at 4:26 PM, Michael Mann <
mmann78@xxxxxxxxxxxx> wrote:
> This is an interesting problem because I'm not sure where the "data crunching" should really be done (GUI vs dissector).
By which you presumably mean "UI code of some sort vs. dissector", because...
> For statistics dialogs, I think more data computation is done in the GUI (taking information from taps).
...*tabular* statistics should, by and large, have as little GUI code of their own as possible, preferably none - that way, the tabular statistic can be used in TShark (write the table to the standard output) and in whatever GUIs are being used for Wireshark (show a table via the GUI) and....
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-
dev@xxxxxxxxxxxxx>
Archives:
https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:
https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
