Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
sergstesh opened this issue Jan 9, 2021 · 7 comments
Assignees

Comments

@sergstesh
Copy link

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

@sergstesh sergstesh changed the title When Gaston produces several Gnuplot windows, only the last one normally interact with mouse and keyboard When Gaston produces several Gnuplot windows, only the last one normally interacts with mouse and keyboard Jan 9, 2021
@mbaz
Copy link
Owner

mbaz commented Jan 9, 2021

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
Copy link
Author

"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(<desired_figure_number>) .

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
Copy link
Owner

mbaz commented Jan 10, 2021

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

@mbaz mbaz self-assigned this Jan 10, 2021
@sergstesh
Copy link
Author

"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
Copy link
Owner

mbaz commented Jan 11, 2021

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
Copy link
Owner

mbaz commented May 28, 2021

@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
Copy link
Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants