Menu
▾
▴
#1418 The "show grid" button doesn't work with the 'qt' terminal
With the gnuplot-qt 4.6.5-4 Debian package under Debian/unstable and the 'qt' terminal (which is now the default): this terminal has a "Show grid" button, but it doesn't have any effect. There was no such problem with the 'wxt' terminal (when it was supported).
To reproduce the problem:
$ GNUTERM=qt gnuplot -persist <<EOF
plot '-' using 1:2 t '' with line
0 0
10 10
e
EOF
Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711139
(already replied via the Debian tracker)
As with the other qt bug report, so far as I known this problem is not present in builds using the upstream source.
The problem only occurs when -persist is used and the main gnuplot program has terminated, e.g. after typing "quit" or with a shell command (or script):
$ gnuplot -persist <<EOF
plot '-' using 1:2 t '' with line
0 0
10 10
e
EOF
The 'wxt' terminal doesn't have such a problem.
Aha. It all becomes clear.
"persist" tells the program to leave the last-displayed plot window open when the main program exits. Depending on the terminal, some mousing operations may still be possible even after the main program has gone away - notably reading out the mouse coordinates. But no, you can't zoom/unzoom, replot, add/remove grid lines or anything else that would require having the main program recreate a modified version of the plot.
Therefore the behaviour you report is normal and expected for all terminal types where the display window is managed by a dedicated process (i.e. not the main gnuplot process). That includes x11, qt, aquaterm, svg, canvas, ...
But as you note the wxt terminal is different. In the wxt case the display window is managed by the same process as the main gnuplot command interpreter. So for wxt "persist" basically means "don't actually exit the program until the plot window is closed". You have also seen the down-side of this. wxWidgets is not entirely happy that the display loop is run in a thread rather than in a separate process. That causes various headaches like the one you are seeing with the Debian build of wxWidgets 3.0. Early in the development of wxt we looked into other options: threads vs separate processes vs a single loop, etc. The current code was chosen because we could get it working on the largest number of platforms, not because it was the ideal choice for any one of them.
Bottom line: this is not a bug, it is the expected behaviour for all linux and OSX terminals except wxt and for most windows terminals as well. Don't exit the main program if you want to further modify the plot.
Probably we should add a generic "help persist" section to the User Manual in addition to whatever the individual terminals have to say about it.
+1. Especially since
qtis the only terminal on Windows wherepersistworks the same way as on other platforms.Documentation added.
The behavior is not satisfactory since in non-interactive mode (as above), gnuplot always exits after the last file is processed. There should be a way to have the main gnuplot program still running until the plot window is closed by the user (e.g. with 'q'). And is there any reason why this isn't done by default when -persist is used?
There are several ways to do that, but "persist" is a red herring. It sounds like what you want is something like this.
$ GNUTERM=qt gnuplot <<EOF
plot '-' using 1:2 t '' with line
0 0
10 10
e
pause mouse key
while (MOUSE_CHAR ne 'K') { pause mouse key; }
EOF
The plot window will remain open and responsive until you hit "K" in the plot window. The point is you don't want gnuplot to exit until you are done, so telling it "persist" is the wrong approach since it means more or less "exit, but leave the last plot showing".
Using "pause mouse" sets an end condition that has to do with mousing. Depending on your actual use you might rather choose a timer (pause \<seconds>) or have it wait for keyboard input in the command window or something else entirely. Input and coordination is pretty flexible, actually. It's just that "persist" is not the right command.
Last edit: Ethan Merritt 2014-06-11
There are several problems with the "pause mouse key" solution. First, the "show grid" button doesn't work, so that there's no improvement over "persist". Moreover, if I close the window, gnuplot is still running. If gnuplot runs in background, this leaves gnuplot processes in background... Note that 'q' is not the only solution to close the window, so that replacing 'K' by 'q' in the condition is not sufficient.
Concerning the documentation, the --persist description in the gnuplot(1) man page should be updated too (without too many details), for instance saying that some features may no longer work with some terminals.
I will look into the what happens with the grid button. I can't think why it would fail, given that more complex operations like zoom/unzoom, toggle, and mouse labeling are still working.
As to 'K', that was just some random key for the sake of an example. You could instead hook it to 'q' or the close event (not tested) or some other condition entirely.
Yes, this solution puts gnuplot in the background. That is exactly what happens currently for wxt, and you're OK with it there, so why is this a problem for qt?
If you mean that the background process doesn't terminate when the plot window closes, I don't see that happen here but maybe you are doing something slightly differently. You could try adding an explicit "quit" to the command stream.
Update the man page - yeah, in fact it may be out of date for other reasons also.
Going all the way back to the top of this tracker thread, you start off by saying that wxt is no longer supported. That is not true. What I gather has happened is that a not-yet-released version of Debian is scheduled to ship with an incompatible version of the wxWidgets library. The normal thing would be to also provide an optional package with the older [current] version, in which case there would be no problem with gnuplot's wxt terminal. But whether or not they choose to do so, it's a self-imposed problem. Gnuplot continues to support wxt and I'm reasonably sure that someone will modify the code to talk more fluently with wxWidgets 3 when it becomes more widespread.
The zoom buttons are also affected.
With wxt and -persist, gnuplot is put in the background, but once the terminal window is closed, gnuplot is no longer running. With qt (without -persist), gnuplot is still running after the terminal window is closed. I'll try to do more tests.
Concerning the wxWidgets library, there are problems with the 2.8 one too, as described in the Debian bug report.
I have only seen forwarded copies your qt-related reports. Could you point me towards the bug report on wxt2.8?
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750045#53
I don't see anything in that tracker about wxt2.8 except some speculation about what might happen if it had a different level of debugging enabled. No actual report of a problem, and no actual test of the debugging level either.
Note that wxt3 now works for me but prints annoying warning messsages. I suspect that the debug level used to build the wxt3 library I am testing against is messed up, but it didn't come from Debian so you may see something different.
Speaking purely as an outsider, my gut feeling is that wxt3 is not quite ready for prime time and that Debian would be making a mistake to drop support for wxt2.8 at this time. How hard can it be to provide a compatibility library? I'm running here with both 2.8 and 3.0 installed and see no problems other than the above-mentioned annoying warnings if I actually link gnuplot against 3.0.
I thought this had been tested. BTW, wxwidgets3.0 also yields problems with xmlcopyeditor. Of course, Debian could support both 2.8 and 3.0. They just want to get rid of 2.8 (for security reasons?) because it is no longer supported by upstream: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748169
I suppose it would be good to start reporting these problem to the wxWidgets people. Even if we can figure out work-arounds so that gnuplot can run with wxWidgets3, to me they indicated regressions in wxt.
For example, having to call XInitThreads() from the main program is really ugly. If the wx library needs that extra initialization, it should arrange to make the call itself. Why should the application (gnuplot in this case) have to pull in the XLib headers and API separately? Now in our case if you were building the x11 terminal anyhow this is not a big deal, but if you were trying to build a wxt-only version of gnuplot then normally all the X11 configuration overhead could be skipped. This change means we have to configure for x11 even if we don't need or want the x11 terminal, just because wxt3 can't get its own initialization right. wxt2.8 didn't have this problem.
The attached patch fixes or at any rate improves the handling of events when the qt plot window is closed manually. This allows the "pause mouse close" command to perform as you would like. Tested with current upstream source and Qt5. The patch applies to version 4.6 also but I have not tested it there.
So your test script becomes:
~~~~~~
$ GNUTERM=qt gnuplot -persist <<EOF
plot '-' using 1:2 t '' with line
0 0
10 10
e
pause mouse close
print "Done"
EOF
Last edit: Ethan Merritt 2014-06-11
Thanks. The patch against 4.6 works. And of course, no need to use -persist.
Closing this because I think the qt issues have been resolved.
There is still the problem that wxt3 is messed up, but we can track that elsewhere. I still think wxt3 is not ready for prime time, and Debian would be making a mistake to rebase everything on it rather than continuing to support wxt2.8. Obviously it's not my call to make.