Re: enhanced_recursion() and do_event(), can they be redesigned?

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

On 02/26/2014 12:46 AM, Bastian Märkisch wrote:
> Am 26.02.2014 06:39, schrieb Daniel J Sebald:
>> On 02/24/2014 09:59 AM, Jérôme Lodewyck wrote:
>>> So could you point out a specific past or present problem in the Qt
>>> terminal that is due to the fact that no event loop is running in the
>>> inboard driver ?
>>
>> The answer is "no". But the follow up to that is I really didn't search
>> for that. I'm trying to solve the problem of the Qt terminal apparently
>> not working on Mac OSX or Windows the way it should in combination with
>> the fact that I don't have Mac OSX or Windows. So I'm striving for an
>> event loop in hopes that makes the setup work better on all platforms. I
>> can't answer your question...that is, without looking into greater
>> detail of the Qt source code.
>>
>
> FWIW, Qt runs nicely on Windows. The only real issue there was to
> implement a way to handle all possible types of events (console, stdin,
> Qt pipe, Windows messages) at the same time. That has been solved in a
> non-portable way, but so is the code using select() on Unix-like
> systems. See the ChangeLog entry on 2014-02-14 and the SF patch tracker
> #645.

There is a lot to read there, but I get the overall idea.  That select() 
(and analogous Windows code) looks like another case of something that 
might be better in the core code.  Looking at qt_waitforinput() it seems 
it cycles through all the possible input modes allotting 1 millisecond 
to input.  Why couldn't the terminal API have a timeout specifier, i.e.,

int qt_waitforinput(int ms)

and then only have the Qt terminal pertinent code while gnuplot core 
watches for the other input routes?

In any case, Qt does have a fairly robust key sequence mechanism, so 
CNTRL-C etc via gnuplot_qt shouldn't be too difficult.  I placed a short 
stream output for the socket name when gnuplot_qt starts up and had no 
problem reading that standard output after waitForReadyRead(), etc.  If 
I understand correctly, Qt queues the standard output until something 
reads it (which would normally be a console or something).  Can't that 
be utilized?

I switched the QProcess to the normal one, not detached, which gives 
better control.  BTW, someone raised the question about persistent 
gnuplot_qt.  Switching this QProcess at least doesn't hurt that 
prospect, as right now I have the gnuplot_qt window hanging around 
always after gnuplot exits (probably a bug).  This weekend I'll attempt 
a good patch of this QProcess change for the patch tracker.

Dan