Ethereal-dev: Re: [Ethereal-dev] RFC framework for graphical extensions like t he recent rate_

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Pavel Mores <pvl@xxxxx>
Date: Fri, 28 Jun 2002 11:28:17 +0200
On Fri, Jun 28, 2002 at 07:02:05PM +1000, Ronnie Sahlberg wrote:

> 2, GNUplot
> GNUplot is not infinitely configurable. However, it is VERY easy to use for
> the majority of uses that
> only need simple graphical output and no interaction with it.
> That GNUplot is external to ethereal is actually a very strong point and not
> a weakness.

Well, I'm not directly opposed to this, however, I wouldn't be that
sure.  It depends on how efficiently are pipes implemented in the host
OS kernel and other conditions that I don't feel you can really count on
being satisfied everywhere.  IPC is one of the worst standardized thing
among different platforms.

> It would allow us to generate extensions WITHOUT tying up ethereal to
> GTK forever.  By writing all the extensions using direct GTK calls, I
> fear that would practically mean that the KDE/Qt/nativeW32/curses
> ports will NEVER happen.  But it does not have to be GNUplot, it is
> whatever program is places on the other side of the pipe created in
> (*start_collecting)(), it could just as well be Matlab,POV,... or
> something else.

That's true but then you have to bear in mind that the external plotter
has to be equally portable as ethereal itself.  Otherwise you end up
with a plugin that doesn't support platforms that ethereal does support.
Which might not be a good thing.

Ethereal already uses Gtk/Gdk heavily anyway.

> If you dont want GNUplot, well dont create a pipe, dont exec gnuplot. Put
> everything yourself inside
> (*draw_graph)()  Its your choice, you can do that if you want to. But you
> dont have to.

That's true.  As long as the design doesn't prevent anyone from using
native calls it's OK I guess.

However, *if* there ever comes a time when external plotter concept and
native drawing contradict, I would prioritize native drawing.  Apart
from the simplest things, if the graphs are to be really useful, if they
are to bring in new non-trivial functionality, they need to be "live"
and interactive imho.

	pvl