Re: wxt term + osx

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

On Tue, 25 Aug 2015, Ethan A Merritt wrote:

> On Tuesday, 25 August, 2015 16:17:52 Allin Cottrell wrote:
>> On Tue, 25 Aug 2015, Ethan A Merritt wrote:
>>
>>> On Tuesday, 25 August, 2015 14:22:05 Allin Cottrell wrote:
>>>> On Tue, 25 Aug 2015, sfeam wrote:
>>>
>>>>> 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-/
>>>
>>> Does it make any persist/nopersist make any difference?
>>> Try activating the FPRINTF in wxt_gui.cpp
>>>
>>>    void wxtFrame::OnClose( wxCloseEvent& event )
>>>    {
>>>        FPRINTF((stderr,"OnClose\n"));
>>>
>>> to monitor whether the window close event is being delivered to
>>> the program.
>>
>> It was being delivered, and I was wrong above: the "done" was coming
>> through on the stdout pipe, it's just that I wasn't reading from the
>> pipe expertly enough. However, if I read correctly and close the pipes
>> when "done" comes through I'm back with my original problem, the
>> window closing right away. Context:
>>
>> set print "-"
>> <various commands>
>> pause mouse close
>> print "done"
>>
>> However... If I ignore the "done" and instead wait for "OnClose"
>> coming out the stderr pipe from wxt_gui.cpp, it works right! The
>> window remains open until deliberately closed, at which point I close
>> the pipes and gnuplot exits.
>
> Okaaay.... but what you are describing is exactly what "pause mouse close"
> is supposed to be doing all by itself - wait in the main thread for the
> OnClose event and not proceed until it arrives.  In other words, if the
> program were executing as intended your test script above could never
> send "done" before sending "OnClose".  So I'm back to thinking that
> the single-threaded version of the pause code is not really waiting for
> the OnClose event as it should.

I think there may be an antecedent problem here in relation to 
wxWidgets. In wxt_gui.h we have:

#ifndef WXT_MONOTHREADED
#if defined(__WXGTK__)
# define WXT_MULTITHREADED
#elif defined(__WXMSW__) || defined(__WXMAC__)
# define WXT_MONOTHREADED
#else
# error "wxt does not know if this platform has to be single- or 
multi-threaded"
#endif
#endif

Now, as I understand it, WXT_MONOTHREADED is defined when this code is 
first reached if and only if the user has deployed the configure 
option --with-wx-single-threaded (described with "do not use 
multithreaded wxgtk even if available"). In my gnuplot build I did not 
use that option; it's not applicable since my wxWidgets on OS X does 
not use GTK, it's cocoa. Therefore we proceed within the cpp block, 
and we skip 'if defined(__WXGTK__)'.

But then what happens? If __WXMAC__ is defined gnuplot then defines 
WXT_MONOTHREADED, but why? My build of wxWidgets 3.0.2 defines 
__WXMAC__, and __WXOSX_COCOA__, and wxUSE_THREADS, so it seems an 
incorrect assumption is being made here.

Allin Cottrell