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

[Ulf Lamping <ulf.lamping@xxxxxx>]

Guy Harris schrieb:
> 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.
>   
Well, reading the mail thread, we seem to have a very special case here 
(that the GTK developers don't really want to handle - which I can 
understand). So using our own widget is what we'll end up in the long 
run anyway I guess.

And I don't even think of it as being that bad, this way we can really 
optimize it for our special needs, so in the long run we'll end up with 
our own "packet list widget" anyway.

My own experiments with the GTK2.x widget (GtkTreeView? it's a long time 
ago) was very slow, but without using the "fixed height" option you've 
mentioned. So if you have a running implementation that get's us in the 
way we want to go (re-fetching data directly from the file instead of 
keeping it in memory) and that's not really falling behind our current 
implementation performance wise, why not try it out.

I mean fetching the column texts from the capture file instead of 
keeping it in memory is enough work for a first implementation step. 
Changing to a GtkTreeView (or alike) later shouldn't be that hard then ...

Regards, ULFL