Re: [Gretl-devel] about the gnuplot backend
On Sat, 19 May 2018, Sven Schreiber wrote:
as a result of discussing the gnuplot integration with the Lyx
people, the
gnuplot readme w.r.t. Windows came up:
"* gnuplot.exe: Text (console) mode version of the gnuplot executable with
full pipe functionality as it is common on other platforms. In contrast to
wgnuplot.exe, this program can also accept commands on stdin (standard input)
and print messages on stdout (standard output). It replaces pgnuplot.exe and
is recommended to be used with 3rd party applications using gnuplot as graph
engine, like e.g. Octave (www.octave.org)."
Despite gnuplot's recommendation, gretl seems to use wgnuplot.exe. Why?
Fair question. The answer is quite long but I'll try to be succinct.
For one thing, we want to be able to offer the user full access to
the gnuplot GUI for Windows, wgnuplot.exe (e.g. under
/Tools/Gnuplot). Given that, the question becomes: Is there any
advantage in also including the console program gnuplot.exe? From
gretl's point of view the answer is No, since wgnuplot.exe works
fine in non-interactive "slave" mode to do what we want -- namely,
accept a script as input and generate a plot file in some specified
output format (PNG for our GUI, but also PDF, EPS, SVG or whatever).
The "selling point" of gnuplot.exe is that it accepts commands on
stdin, but the way gretl interacts with gnuplot we have no need for
that facility. There are basically two ways in which a program like
gretl or Octave can make a gnuplot plot modifiable by the user.
(1) The plot's "state" can be saved on the gnuplot side. It is shown
in a gnuplot window, and incremental commands to modify it are sent
to gnuplot via stdin. This is what gretl did in the old, old days.
(2) State is saved in the caller (gretl). The plot specification
takes the two interchangeable forms of a gnuplot script and a C
struct which represents the content of the script in a structured
manner in memory. When the user requests a modification gretl
rewrites the script, recompiles the plot to PNG via gnuplot, and
reloads it into a GTK window.
By adopting method (2) we're able to show our plots in (I would say)
a "nicer" window than the native gnuplot one. It's easier to get a
consistent appearence across platforms, and we're able to attach a
much more functional menu system.
Oh, and one more thing: we need wgnuplot to show 3-D plots that can
be manipulated interactively.
To be clear: the "compilation" of gnuplot scripts to PNG (etc.)
could certainly be accomplished using gnuplot.exe instead of
wgnuplot.exe; it's just that since we want wgnuplot.exe anyway
there's no advantage to packaging a second gnuplot executable.
Allin