Re: Reworked qt terminal is much faster – and fails to work on Mac

[Daniel J S. <dan...@ie...>]

On 03/02/2014 07:02 PM, sfeam wrote:
> On Monday, 03 March 2014 01:41:06 AM Mojca Miklavec wrote:
>> On Sun, Mar 2, 2014 at 11:28 PM, Daniel J Sebald wrote:
>>>
>>> I wrote a clean patch which I placed here
>>>
>>> https://sourceforge.net/p/gnuplot/patches/653/
>>
>> I first faced problems with "plugin"
>>
>> Making all in plugin
>> /bin/sh: line 0: cd: plugin: No such file or directory
>
> That's a totally separate problem.
> The new .../demo/plugin directory is not being handled properly
> by autoconf/automake.  I don't know how to fix it, but the answer
> for now is to use
>   ./configure --disable-plugins
>
>> but after manually patching the Makefile (there is a fair chance that
>> my setup is semi-broken in that respect, so I don't blame the sources
>> until I do a few more tests from a totally clean CVS checkout), here
>> are the initial problems again:
>>
>> gnuplot>  plot sin(x)
>> qt_sendFont: Not receiving font properties
>> qt_sendFont: "QLocalSocket: Socket operation timed out"
>> gnuplot>  qt_processTermEvent received a GE_fontprops event. This
>> should not have happened
>>
>> The plot finally appears after 15 seconds, without any labels, wrong
>> window size (that's also a problem in trunk/HEAD). Gnuplot then never
>> properly recovered (I never got any text labels).
>>
>> The second gnuplot run works.
>>
>> These are exactly the symptoms that Ethan fixed recently.
>
> Yeah. I put my comments on the patch tracker, but in short the patch
> removes exactly the fixes I put in to handle the slow OSX font response.
> So I don't think this patch is going in the right direction for event
> handling.
>
> The initial fork+and wait of the external process may be cleaner in
> Dan's patch than it was before.  But I think we should leave the event
> handling the way it is now.

OK, it's easy enough to pull out the few hunks for fork/wait and create 
a separate patch.

Dan