LEGO wrote:
Attached you will find:
- gtk/gtk_stats_tree.[ch] the code for the stats_tree tap-window
I don't see any use of GTK+ data structures in gtk/gtk_stats_tree.h.
I also don't see any in gtk/ip_stat.c.
Does that mean that, in fact, all the GUI code is in
gtk/gtk_stats_tree.c, with no GUI code in any of the taps that use it,
and that it might be possible to write a *Tethereal* implementation of
the "stats_tree" code, and that taps that use this mechanism could not
only be GUI-independent (all a particular GUI would need would be an
implementation of the "stats_tree" code?
If so, perhaps "gtk/gtk_stats_tree.h" should just become a top-level
"stats_tree.h", and "gtk/gtk_stats_tree.c" should become
"gtk/stats_tree.c", and we should consider doing a Tethereal
"stats_tree" implementation (which would print out the statistics to the
standard output), and move taps that use the "stats_tree" code to the
top-level Ethereal directory and build them into both Ethereal and
Tethereal.
The next step might be to add support for those types of taps as plugins
- the same loadable module could be loaded by Tethereal,
Ethereal-for-GTK+, a future Ethereal-for-native-Windows, and
Ethereal-for-other-GUIs.
(Another step after that might be to have a more generalized "tree
display" framework, where the tap would specify, when creating the
table, some title information and an array of column descriptions, with
each column having:
a title;
a type (string, numbers of various sorts, network addresses of various
sorts or perhaps just generic addresses complete with AT_ values, etc.);
perhaps other properties;
and could then add rows to that tree, with each row having an array of
column values - the call to add a row might return a handle of some
sort, so that additional rows could be added under that row, and that
handle could also be used to *update* a row with new values.
Implementations of this would either display it as a tree or print it to
the standard output - and the "print it to the standard output" code
might be used in Ethereal with a "Print" button.
If the stats_tree mechanism could be implemented atop that, we'd do
that. We might also be able to reimplement some other taps atop that,
which might let us combine some Ethereal and Tethereal taps into a
single tap. Taps using that mechanism could also be plugins.)
- a patch to gtk/isup_stat.c (which replaces thee old window with the newer one)
Unfortunately, that patch didn't work - I don't know whether the problem
is that it wasn't generated with the current version of gtk/isup_stat.c
or not, but the patch was rejected (and, as it appears to, as you
indicate, replace most of the lines in the file, applying the rejected
parts manually would take a lot of work...). (The $Id$ line in the
"before" part of the patch is just "$Id$", which doesn't match what's in
the current version of the source.)
I don't know if it runs under GTK1.
We might then want to wait until 0.10.9 is released before checking this
in, as it won't work under GTK+ 1.2[.x] (it uses the GTK+ 2.x tree view
and tree model widgets, which aren't in 1.2[.x]) - that means that we'd
have to avoid compiling it, or the taps that use it, when building with
GTK+ 1.2[.x] until a GTK+ 1.2[.x] implementation is done (using the
GtkCTree widget), and we probably don't want to eliminate those
statistics for 0.10.9.
If somebody can implement a GTK+ 1.2[.x] version before 0.10.9 is
released, we could check it in then, but otherwise I'd recommend waiting
until 0.10.9 is released.