#1659 Mouse zoom does not work with --persist
Gnuplot version 5.0 running on Linux_x64 Fedora 22, gnome 3.6
Gnuplot 5.0 does not seem to allow mouse-based zooming (right mouse button sweep) when --persist is used, e.g.
gnuplot --persist xyz.dat
I have tried terminal qt and x11 and both have the same problem. If instead I run gnuplot interactively and do load "xyz.dat" everything works as expected.
This seems to be a clear departure from 4.x, for which mouse zoom worked fine whether I used gnuplot interactively or in batch mode.
Is this something that you acknowledge as a real bug, since I have seen some posts where this was questioned?
It is not convenient to run gnuplot interactively just to get mouse functionality, and again, it is a regression from 4.6 so I hope you will consider fixing it.
Thank you.
This is not a change. Mouse zooming (and redraw and log-scale and etc etc) are not possible after the main program has exited. This has always been the case for x11, since the x11 display driver is a separate program from the main gnuplot program. Qt also works this way. wxt behaves slightly differently from the others, since wxt requires the main program to stay around.
Ok, so I checked and the 4.6 version used wxt terminal by default. It seems my version does not come with wxt support out of the box on fedora 22. But there is a gnuplot-wx package that does do exactly what I'm used to (wxt terminal) so I'm good to go. Problem solved. Thank you.
Since wxt is no longer available, it would be fair to reopen this (along with #1483)
The current status, I'm afraid, is that wxt formerly satisfied an important need (--persist+interactivity), that qt doesn't. This is a gaping feature hole.
Of course I don't expect an immediate admission of the error ; so here is a workaround.
The attached script, named "xwinkill", will spawn a process (gnuplot in our case), then use xwininfo and xprop to probe into the X11 server state and detect a window associated with the process ; then it will use xev -spy to get immediate notification of its fate, and kill the process when the window is closed.
Example for gnuplot:
Complete example with another program "src" generating commands, then exiting:
Note the while loop is there to circumvent gnuplot's annoying tendency to die on EOF (since --persist is definitely unusable for our purpose), and yet be notified by SIGPIPE when it dies from xwinkill's hands.
Last edit: Alexandre Ferrieux 2016-07-21
Huh? What do you mean wxt is no longer available?
The transition from wxgtk2 to wxgtk3 was a bit rocky due to library incompatibilities, but gnuplot has supported the wxt terminal throughout. I don't see any outstanding bug reports against wxt on our bug tracker. Do you have one to report?
Having said that, I suspect that the qt terminal would also do fine for your purpose. You just need to realize that "persist" is apparently not the right option. Probably "pause mouse close" does what you want.
Maybe things have improved upstream, but what about distro-packaged version ?
Take Debian Stable: I am not aware of a packaged gnuplot with the wxt terminal. Is there a specific add-on ? Or a plan to reintroduce it in the main package anytime soon ?
Re "pause mouse close": depends on exact versions. On some, the gnuplot process doesn't really die when the window is closed; instead it falls into an infinite loop of usleep(10). One could bisect and find whether "pause mouse close" starts really working before the end of (packaged) wxt support...
If you have questions about distro packaging (Debian, Fedora, etc) you will have to direct them to the distro in question. I am at least somewhat aware of issues in Debian because the Debian packager forwards them to this tracker and we have in the past worked together to address them. I have never had any contact from Fedora with regard to either bugs or packaging issues.
Regardless of your distro packaging, it is pretty easy to build gnuplot directly from the source. That way you can configure in or out any terminal support that you want.
If you have diagnosed a problem with "pause mouse close" please go ahead and file a bug report.
1) The most recent relevant item I can find in gnuplot's ChangeLog is a bugfix from Sep 2015 that affected Windows and OSX. It could potentially have affected the wxt terminal on linux but only if it had been configured not to use threads (no actual bug reports on this one, I'm just going by the code path that was touched by the bugfix patch). The first release version containing that fix was 5.0.2 (Jan 2016).
2) Prior to that, I see a qt-specific bug that was fixed in version 4.6.6 (Sept 2014). That might be the one you are thinking of, but the fixed version is old enough that I would have expected distros to be carrying it by now.
Last edit: Ethan Merritt 2016-07-22
In some cases, recompiling is not an option. For example, when you distribute something that's small, you don't want to carry along each and every big dependency, like gnuplot. Hence the focus on distro packaging.
In this context, I'm saying that a "few" machines today (those on Debian Stable) have no prepackaged way to use wxt. You might not care much about distros, but that's still a fair lot of people. If you run into the Debian packager someday, be sure to ask him why this is so, given what you've said before about wxWindows issues being over.
Will look into the status of the "pause mouse close" bug in my older machines and report if I see it post 4.6.6.
In some cases, recompiling is not an option. For example, when you
distribute something that's small, you don't want to carry along each and
every big dependency, like gnuplot. Hence the focus on distro packaging.
In this context, I'm saying that a "few" machines today (those on Debian
Stable) have no prepackaged way to use wxt. You might not care much about
distros, but that's still a fair lot of people. If you run into the Debian
packager someday, be sure to ask him why this is so, give what you've said
before about wxWindows issues being over.
Will look into the status of the "pause mouse close" bug in my older
machines and let you know their age relative to 4.6.6.
It was a combination of unfortunate timing and (IMHO) an overly aggressive desire to drop the wxgtk2.8 library from the Debian stable core package list. At the time they were deciding what would or would not make the cut for Jessie, gnuplot was still using wxgtk2.8. In the event, gnuplot on wxgtk3 was working fine by the time of the actual Jessie release but they had long since frozen the package list.
IMHO it was foolish to drop wxgtk2.8 from Jessie. gnuplot is far from the only package that still wanted it (the dependency list gave 200+ such packages when I checked). I made that argument at the time but my influence was and is miniscule. If you want to levy blame, I admit to assuring the Debian packager that a qt-based gnuplot package would be a more than adequate substitute for the previous wxgtk-based package.
I have had no involvement with Fedora packaging so I can't offer any insight there.
Thanks for the clarification on the wxgtk "hole".
So I scanned a few of my machines, with the yum- or apt- available packaging of gnuplot for their current status. Report:
RHEL5.5: gnuplot 4.0.0 ; no wxt ; pause mouse doesn't understand "close"
Fedora 12 : gnuplot 4.2.6; wxt present with -persist working as needed ; "pause mouse close" looping on usleep(10)
Debian 7 (Wheezy) : gnuplot 4.6.0 ; wxt present with -persist working as needed ; "pause mouse close" working properly
Debian 8 (Jessie) : gnuplot 4.6.6 (package "gnuplot") or 5.0rc2 (package "gnuplot5") ; no wxt ; "pause mouse close" working properly
You can see how easy it is to get nervous about depending on features across the board.
An external ugly hack like xwinkill, as disgusting as it is, seems to be the only way.
Last edit: Alexandre Ferrieux 2016-07-23
I sympathize with the pain of imperfect backwards-compatibility. But complaining that gnuplot 4.0.0 didn't support wxt or "pause mouse close" is more than a bit unreasonable. That version is more than 12 years old; the wxt terminal was not even written until several years later.
Fedora 12 reached end-of-life more than 5 years ago (Dec 2010). Even so, the current gnuplot version at that time was 4.4.something. I cannot explain why Fedora was not providing a more up-to-date gnuplot. I was under the impression that they were more likely to package bleeding-edge software versions rather than old-in-the-tooth versions.
So yeah, if what you need is 100% compatibility all the way back to installations running binaries compiled before either the wxt or the qt drivers existed, I guess that limits you to using the x11 terminal.
I think the gnuplot project is far more serious than most about maintaining backward compatibility. But this means new versions can run scripts written for older versions. It does not mean that scripts written for new versions will run on all older versions. And of course you realize that bug-fixes only help users who upgrade to a fixed version of the program.