Re: wxt term + osx

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

On Tue, 25 Aug 2015, sfeam wrote:

> On Tuesday, 25 August 2015 11:00:42 AM Allin Cottrell wrote:
>> 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.
>> 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.
>
> That is true for the x11 and qt terminal drivers, which are managed
> by the separate processes gnuplot_x11 and gnuplot_qt respectively.
> Your description is not quite correct for wxt.  Rather than two
> entirely separate processes, the wxt terminal uses either a single
> thread (OSX) or two threads (linux) by default.  Some people have
> reported that they have better luck running a single thread on linux
> also, but that may be due to early/buggy versions of wxgtk3.
>
>> 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.
>
> Yes.  Because it is not a separate process, the main gnuplot thread
> stays around when the wxt terminal is in persist mode.  This is unlike
> other terminals.
>
> The single- and multi- threaded versions use a different section of
> code in the routine wxt_gui.cpp: wxt_waitforinput()
> It sounds like there is some tweak needed for the single-threaded
> code block so that it doesn't exit if "pause mouse close" is active.
>
> You could try adding a check for
>  if (!paused_for_mouse)
> or maybe it would need to be
>  if ((paused_for_mouse & PAUSE_WINCLOSE) != 0)
>
> before breaking from the loop that starts at line 3869.
> But I'm not sure... that might cause it to hang in other
> circumstances.

Thanks for the hint, I'll give it a try.

In the meantime, something related: I tried hooking up all relevant 
pipes via g_spawn (gnuplot's stdin to pipe in the script, and 
gnuplot's stdout to read messages). My idea was, after "pause mouse 
close" get gnuplot to print "done" (with print set to "-"). So when we 
read "done", close all pipes and gnuplot should shut down.

This works fine on Linux, but not on OS X: "done" never gets printed, 
or in other words closing the wxt window does not trigger "close" so 
far as pause mouse is concerned. The pause is either non-existent or 
permanent 8-/

Allin Cottrell