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.
