On Mon, 17 Jan 2005 01:01:40 -0800, Guy Harris <gharris@xxxxxxxxx> wrote:
> > Attached you will find:
> 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?
Yes, I meant it to allow for the same tap code to be usable with both
gtk and tethereal.
> 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.
I got the string version of the tree ready. I haven't yet got into
putting it into 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.
Guess what... I've like to do that with mate!
[snip]
> 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.);
that would solve at least the sorting problem.
> 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.
It does already. "tick" and "add" return a string used to refer to
them as parents.
> 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.
Yes
> 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.)
I think is worth unifying all of them so that eveeryone benefits from
improvements to the stats_tree
[snip]
> 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.
I think is better we wait for a next release.
I've got some more work done on it,
- text-only version of a branch of the tree
- an aborted attempt to use the text-only version to make a GTK1 version
I'll put those on the list in few days.