Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Question regarding QT/future Wireshark version

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 5 Jan 2012 12:22:33 -0800
(Small note: it's "Qt", capital-Q-lower-case-t, not "QT", capital-Q-capital-T; I've mostly seen "QT" used as an abbreviation for "QuickTime" from Apple.)

On Jan 5, 2012, at 11:42 AM, Stephen Fisher wrote:

> 
> ---- On Thu, 05 Jan 2012 08:04:58 -0700 Roland Knall  wrote ---- 
> 
>> Is there a point in the forseeable future, where new development for 
>> the GTK version will cease to exist (and just focus on bug-fixing) and 
>> all further development should go into the QT version? 
> 
> Considering that the "new packet list" effort took multiple years and that was just using a different part of GTK to implement our packet list,

Well, to be fair, the "new packet list" switched from using a part of GTK+ that required that the list be pre-populated with all the column strings to using a part of GTK+ that allowed the column strings to be generated as needed, *and* that we used that capability to speed up a bunch of things by reducing memory requirements and not requiring column strings to be re-generated on some changes (e.g., time format changes), there was more to it than just using a different GUI widget to display the packet list.

> the move to QT will take quite a while.  Our fast and complex use of the GUI mainly with the packet list takes a surprisingly large amount of work to (re-)implement.

Hopefully we're using a Qt widget that supports generating column text as needed, similar to what the *new* GTK+ widget does, so that the as-needed generation of the columns would work similarly.

>> The reason for my question is, that I currently are implementing some 
>> add-ons for the openSAFETY and EPL dissectors. I would prefer if I 
>> could avoid redoing significant parts of the implementation, and start 
>> with QT right away. 
> 
> Is there any GTK specific parts?  Usually, Wireshark handles the GUI for you.

If the add-ons are in the dissecting code, there's no GUI code there; Wireshark handles the GUI display, and TShark handles the text output.  I doubt that we'll be linking TShark with Qt, so I don't think its non-GUI classes will be available for dissectors to use.  (Qt isn't, as far as I know, split into a "non-GUI utility library" like GLib and a "GUI toolkit" like GTK+.)

If the add-ons are statistics taps or something such as that, alas, Wireshark *doesn't* handle the GUI for you unless the "stats tree" stuff can be used, and I don't think that stuff is general enough to, for example, replace all the service-response-time statistics we have (and which have both TShark and Wireshark implementations, duplicating a large chunk of their code).