Maybe while doing these changes, the much talked about "split" of the
plotting code from octave could also be implemented? I have no idea
how, but it seems that the gnuplot interface will undergo not so minor
changes so it's a good time to at least do it in way which will be
consistent with the future plan to split the gnuplot code.
On 10/11/05, John W. Eaton <jwe@...> wrote:
> On 11-Oct-2005, John W. Eaton wrote:
> | On 10-Oct-2005, Paul Kienzle wrote:
> | | Any idea how difficult it would be to extend octave/gnuplot to suppor=
> | | multiple figures natively?
> | The fix for Octave, independent of any changes to gnuplot, would be to
> | open a separate connection to gnuplot for each figure (i.e., one
> | gnuplot process per figure). In the current sources, you'd need to do
> | this in the src/DLD-FUNCTIONS/gplot.l file. Instead of
> | // Pipe to gnuplot.
> | static oprocstream *plot_stream =3D 0;
> | we might want
> | // Pipe to gnuplot.
> | static oprocstream *current_plot_stream =3D 0;
> | std::map<int,oprocstream *> plot_stream_map;
> | to map figure numbers to plot stream objects.
> | The current figure.m should maybe become a built-in function that
> | handles opening plot streams and manages the plot_stream_map and the
> | variable __current_figure__. Currently this variable is only defined
> | as a global in the scripting language, but that should probably become
> | a variable in gplot.l that is exported to the scripting language.
> I looked at this a bit more and I think the variables
> // The number of lines we've plotted so far.
> static int plot_line_count =3D 0;
> // Is this a parametric plot? Makes a difference for 3D plotting.
> static bool parametric_plot =3D false;
> // The gnuplot terminal type.
> static std::string gnuplot_terminal_type;
> will also need to be per-process variables, and the functions that
> handle opening and closing the plot stream will need to be changed.
> Probably all the per-process data should go in a separate class.
> You'll want to be able to look up a process given a figure number or a
> PID (for the plot_stream_event_handler). The oprocstream object contains
> the PID, so you shouldn't need to duplicate that, but you will need to
> be able to go from PID to oprocstream object. Etc. There are quite a
> few details. I think the current code could use some cleaning up.