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

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

On 02/16/2014 05:47 PM, Daniel J Sebald wrote:

> 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.

Things are slowly coming along, but I've become rather busy with a 
number of projects at work.  I would like to point out that I have a new 
way of waiting for the gnuplot_qt server to be active that avoids that 
clumsy while loop.  Here's a brief summary if Ethan wants to try and 
tweak the CVS repository.  Otherwise, what I will have is a fairly big 
diff file in the coming week.

It's fairly simple, really.  But first, I'd like to ask if it is alright 
to create the process not as detached, but just a normal process.  Is 
that OK?  If that is done, then after starting the QProcess that will 
create the local server, just wait for the process to write back the 
server's name and continue onward.  By writing the local server name to 
standard output (fprint/fflush) when everything is set up and ready to 
go, the first time that qt_term attempts to connect to the local server 
will be a success.


IN QT_TERM.CPP:

     if (!qtgnuplotProcess)
         qtgnuplotProcess = new QProcess();
     qtgnuplotProcess->start(filename, QStringList());
     if (qtgnuplotProcess->waitForStarted())
     {
         qtgnuplotProcess->waitForReadyRead();
         localServerName = qtgnuplotProcess->readAllStandardOutput();
         qDebug() << localServerName;
     }
     else
     {
         qDebug() << "QProcess starting failed:" << 
qtgnuplotProcess->errorString();
     }


IN QTGNUPLOTAPPLICATION.CPP:

QtGnuplotApplication::QtGnuplotApplication(int& argc, char** argv)
	: QApplication(argc, argv)
{
...
     connect(m_eventHandler, SIGNAL(disconnected()), this, 
SLOT(enterPersistMode()));

     fprintf(stdout, sName.toLocal8Bit().data());
     fflush(stdout);
}

Dan