Re: wxt term + osx

[Allin C. <cot...@wf...>]

On Tue, 25 Aug 2015, Jun T. wrote:

> 2015/08/25 12:43, Allin Cottrell <cot...@wf...> wrote:
>
>> But if I do the same thing programmatically (using the GLib function
>> g_spawn_async) the wxt window appears momentarily, with the plot
>> looking OK so far as I can tell, then disappears right away. The
>> GLib call seems to be correct; it works as intended on Linux.
>> Somehow on OS X the "pause mouse close" isn't preventing the
>> termination of the gnuplot process.
>
> I have no experience with glib, but I guess the stdin of the
> spawned gnuplot is set to /dev/null, so the gnuplot thinks it
> should quit (as if you typed ctrl-D in the terminal = EOF).
>
> On Linux, wxt window is managed by a separate process from the main
> gnuplot process. But on Mac, gnuplot+wxt is a single process, and if
> the main gnuplot quits then the plot window will go away.
>
> You may try setting the G_SPAWN_CHILD_INHERITS_STDIN bit in the
> 'flags' (the 4th arg of g_spawn_async()), so that the gnuplot will
> inherit the stdin from the parent.

Thanks, your diagnosis seems to be accurate. Unfortunately the program 
from which I'm calling gnuplot is a GUI program so it doesn't have a 
STDIN that gnuplot can inherit.

I have found one way to get gnuplot/wxt to stay open in this context 
bit it's seriously clunky: write out a shell script that calls gnuplot 
with the plot-script argument, then use system() to call Terminal.app 
to execute the shell script. The Terminal.app window is just in the 
way and doesn't close itself on exit.

One thing I'm still not getting: you're right that g_spawn sets the 
child's stdin to /dev/null by default, but then I wonder how gnuplot 
stays open on Linux? As I understand it, gnuplot itself must still be 
running if the 3D plot can be manipulated with the mouse.

Allin Cottrell