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

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

On 02/12/2014 08:50 PM, Daniel J Sebald wrote:
> On 02/12/2014 02:49 PM, Thomas Bleher wrote:
>> * Daniel J Sebald<dan...@ie...>   [2014-02-12 06:36]:
>>> In any case, I suggest adding the sleep as Ethan has done.  There is
>>> no reason that should be running at 100%.  In fact, there is
>>> probably a preferred way to do this without polling loops.  I
>>> learned a little bit about Qt working on Octave and Qt has this
>>> paradigm of signals and slots and the developers suggest adhering to
>>> the concept otherwise can get kind of dodgy (not in this simple
>>> case...but cases where widget IDs are floating about).
>>>
>>> signal:  something that a Qt object emits
>>> slot:  the destination of the signal which can
>>>          be of any number, e.g., five other
>>>          objects could connect a slot to a signal
>>>
>>> Anyhow, I don't have time to look at this right now, but if one
>>> looks at the documentation for a Qt socket:
>>>
>>> http://qt-project.org/doc/qt-4.8/qlocalsocket.html#connectToServer
>>>
>>> it indicates that a signal is emitted when the connection is
>>> complete and there is a signal emitted when there is an error.  So
>>> the proper thing to do is to first make connections to the socket
>>> sort of like the following ("success" and "failed" are custom member
>>> functions):
>>>
>>> connect (createdsocket, SIGNAL (connected ()), watcher, SLOT (success ()));
>>> connect (createdsocket, SIGNAL (error ()), watcher, SLOT (failed ()));
>>>
>>> and then tell the socket to attempt to connect to the server:
>>>
>>> createdsocket->connectToServer (name)
>>>
>>> There is no need to check in a loop for anything.  Either the socket
>>> will successfully connect and emit "connected" at which point
>>> "success()" will get called or the socket will timeout and emit
>>> "error" at which point "failed()" will get called.
>>>
>>> One can get very creative about connections made, the number of
>>> slots watching a signal, doing this dynamically, etc.  So instead of
>>> a recursive routine, it might be multiple connections, or
>>> dynamically reconnect/disconnect in the "failed()" slot.  Etc.
>>
>> signals and slots are indeed very nice, but they need a Qt event loop to
>> work correctly. I don't think it is possible to add the Qt event loop to
>> gnuplot without major surgery. (Well, you can start a local event loop
>> using QEventLoop inside a function, but in this case it's just more work
>> to get the same result we already have).
>
> Good point, but we'll see if we can make it work somehow.  It's worth at
> least a couple hours time to test whether it is feasible.  It would seem
> that the place to start the Qt event loop along with setting up initial
> signals/slots would be upon calling "term qt".  The good thing is that
> the graphics is done in the satellite Qt program.  The bits accessible
> to gnuplot core don't need graphics, so perhaps that Qt event loop could
> be run in a different, non-main thread without too much work.

I've a good start on the separate thread for Qt.  I think it is going to 
work, but it will probably be next weekend until I finish.  I just don't 
have the time right now.  So Mojca, you'll have to wait a week I guess.

It's been pretty straightforward up to this point.  I just laid things 
out the way the Qt documentation shows.  The separate thread starts and 
now timers definitely work as expected.  I have signals going across 
without much problems.  The external program gnuplot_qt shows up.  There 
are two remaining issues:

1) Timing.  Since this is signaling into a thread rather than calling, 
the signal returns right away and gnuplot core continues onward not 
having valid values for settings (i.e., x, y dimensions, etc.).  While 
that goes on, the other thread has problems and 30 seconds later 
complaints show up in qDebug(), and 30 seconds later once again, and 30 
seconds later is the last try.  I know how to fix this.  It just takes a 
QMutex and putting it to sleep and have the object in the QThread wake 
it when it has finished or timed out.  I've done it before.

2) Reorganization.  I think the number of ways connectToServer tries to 
connect can be simplified, without recursion.  The complaints from Qt 
are along the lines of some child objects being created in a thread 
different from its parent.  Shouldn't be difficult to fix with some 
better reorganization.  I've already broken the Qt class declarations 
into individual files QtTerminalEmitter.h (same main thread as gnuplot) 
and QtTerminalInterface.h (separate thread), which is similar to the 
rest of the Qt code in the qtterminal directory.

More next weekend or later in the week.

Dan