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

Wireshark-dev: [Wireshark-dev] Requiring GTK+ 2.4 or later

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Sun, 27 Apr 2008 00:19:13 -0700
Jeff Morriss wrote:
packaging/svr4/checkinstall.in also uses the GTK version for install-time dependency checking but I can't seem to figure out how to get a variable in configure.in to populate that file when it builds the real file.

(OTOH it would be convenient for me to keep GTK < 2.4 but...)

At least at one point, I seem to remember reading that the GtkTreeView was changed in GTK+ 2.4 to deal with a performance issue. A little searching indicated that this was the addition of a "fixed height" option, so it didn't have to calculate the height of every single row:

	http://lists.wxwidgets.org/pipermail/wx-dev/2006-October/078556.html

which would probably be OK for the packet list if we were to switch to using a GtkTreeView, which would let us change the columns without destroying the packet list and reconstructing it, and would also let us avoid allocating strings for the content of all rows and columns by having a tree model that dissects packets on the fly (that requires support for fast random access to packets even in compressed files, but that's probably doable).

However, there might be some other issues with the GtkTreeView and large capture files:

	http://inverted-tree.livejournal.com/58999.html

	http://mail.gnome.org/archives/gtk-devel-list/2008-February/msg00032.html

	http://mail.gnome.org/archives/gtk-devel-list/2008-February/msg00035.html

although that thread included

	http://mail.gnome.org/archives/gtk-devel-list/2008-February/msg00040.html

which has a rather familiar use case :-), and the custom TreeModel is exactly what I've thinking of; perhaps that would avoid the problems being discussed.

Alternatively, I had a version of the GTK+ 1.2.10 GtkClist modified to fetch the column strings by calling a routine associated with the CList; I could try to make those modifications to the GTK+ 2.x GtkClist, and use that, although that has the disadvantage that we'd be maintaining our own version of a (deprecated) widget.