When Gaston produces several Gnuplot windows, only the last one normally interacts with mouse and keyboard

[sergstesh]

I have decided to switch to 'x11' terminal because it seems to be more responsive than the 'qt' one, but I think the problem manifests itself with the 'qt' one too. To reproduce the problem start Julia and copy-paste the following code:

using Gaston;

closeall();

set(term = "x11");

y = vcat(1:10) .* 1.0;

_1_ = plot(1.0 .* y)
figure()
display(_1_)

_1_ = plot(2.0 .* y)
figure()
display(_1_)

_1_ = plot(3.0 .* y)
figure()
display(_1_)

The code produces 3 Gnuplot windows.

When I try to resize window number 3 (the last one) and when I try to zoom in using mouse, and when I replot using 'a' keyboard shortcut, etc, everything works as expected.

However, if, for example, I try to resize window number 2, it gets resized, but the plot is not redrawn, it gets tiled. When it happens, plot in window number 3 is affected (e.g. changes aspect ratio). Keyboard shortcuts and mouse do not work in window number 2.

I remember working with GNU Octave and its Gnuplot graphical backend that each new Gnuplot window was causing new Gnuplot instance (system process) to be produced, but all Gnuplot windows functioned normally and changes in one window did not affect others. It seems that Gaston produces only one Gnuplot instance (to be more exact, one 'gnuplot' and one 'gnuplot_x11', but likely the latter begets the former) :

sergei@sergei-dt:/mnt/althome/sergei/LensEq_work$ ps auwx | grep gnuplot
sergei   18426  0.0  0.1 178940 16632 pts/67   S+   14:55   0:00 gnuplot
sergei   18427  0.0  0.0  35844  4264 pts/67   S+   14:55   0:00 gnuplot_x11
sergei   18522  0.0  0.0  14436  1016 pts/66   S+   15:06   0:00 grep gnuplot
sergei@sergei-dt:/mnt/althome/sergei/LensEq_work$

So maybe the fact that there's no Gnuplot instance per Gnuplot window is the root cause of the problem.

My system:

Linux sergei-dt 4.15.0-99-generic #100-Ubuntu SMP Wed Apr 22 20:32:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux . Gnuplot version:

gnuplot-x11 --version
gnuplot 5.2 patchlevel 2

[mbaz]

As you found out, the reason for this behavior is that Gaston creates only one gnuplot process, which handles all plots. The advantage is that only one process is created; the disadvantage is that gnuplot can only interact with one plot at a time.

To help in this situation, Gaston has the figure() command. Executing figure(x) will cause the plot with handle x to become current, and all subsequent mouse/keyboard/Gaston commands will only affect plot x.

So, this behavior is by design, and I believe it is a good compromise between efficiency (one single gnuplot process) and convenience (having to use figure()). What do you think?

[sergstesh]

"What do you think?" - I think it should just work as it does in GNU Octave. I had literally more than a hundred Gnuplot windows open monitoring generation of some dataset. I actually even ran out of available child processes - after that I was limiting the number of plots.

The real issue is that as a long calculation is being run, I can't interactively set figure() .

Maybe you can introduce a 'gnuplot_instance_per_plot_window' option, and for that matter another 'plotting_as_side_effect' option - because it's too cumbersome now achieving display of multiple display windows. I.e. the default need is multiple plot windows - not a single one, while Gaston code on user's side is minimal for single plot window.

Conceptually speaking I am a fan of functional programming paradigm - one of the reasons I want to forever abandon GNU Octave/Matlab (another reason being the possibility of strict typing), but on the other hand output is by definition side effect.

[mbaz]

This wouldn't be a trivial change, but let me think about it and see what I can come up with.

[sergstesh]

"let me think about it and see what I can come up with" - thanks for the intent.

I hope you realize that real life usage of plot utility means practical need of several interactive windows while the calculations are still being performed.

"Several" above is because one window can't contain too much data, and because the data maybe kind of "mutually exclusive". For example, I deal a lot with DSP, the "mutually exclusive" data is frequency response vs impulse response.

In my applications calculations may run for hours, so I need interactive plot windows to monitor correctness of data at several checkpoints in the data generation flow. If a problem is detected, the calculations are terminated and corrective actions are taken. Without the interactive feature it's impossible to examine data at the checkpoints, so the calculations have to be to the very end.

So, I hope, you understand I am describing real life development and debugging scenario. The requested functionality exists in GNU Octave, Scilab, Maxima, Matlab, etc.

[mbaz]

I understand the scenario you describe. That is why I'm considering addressing it, even though it's a non-trivial amount of work. I hope you also understand that that scenario is not universal; I also do research in DSP and the functionality I built into Gaston has always been sufficient for me.

[mbaz]

@sergstesh Just a quick note: this is implemented and functional in my local branch, which will become 2.0 sometime in the near future.

[sergstesh]

@sergstesh Just a quick note: this is implemented and functional in my local branch, which will become 2.0 sometime in the near future.

Thanks.