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

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

On 02/24/2014 09:59 AM, Jérôme Lodewyck wrote:
> Hi,
>
> I got a bit confused about your motivations for introducing an event
> loop in the "inboard" qt terminal. In qt_term.cpp, we use, by design, a
> very limited set of the Qt library, and rather push as much
> functionality as possible the in the gnuplot_qt "outboard" program.

That's all fine.  I've no intention of moving anything from gnuplot_qt 
over to the qt_term.cpp.

I've written several times that the reason for supplying an event loop 
to the code is because I'm suspicious of the overall functionality of Qt 
code on all platforms without the event loop.  But read on below...


>  And
> I think that this set of functions doesn't require an event loop to work
> properly (As a matter of fact, I can observe by commenting out the
> QCoreApplication declaration in qt_term.cpp that it doesn't even require
> an instantiation of QCoreApplication to work -- except from the Windows
> specific QCoreApplication::applicationDirPath() call). More
> specifically, we use
> - Storage classes (QString, QImage, QColor...) that just gather
> information but use no event mechanism.
> - QLocalSocket that, according to the Qt documentation, can work without
> an event loop:
> "Although QLocalSocket is designed for use with an event loop, it's
> possible to use it without one. In that case, you must use
> waitForConnected(), waitForReadyRead(), waitForBytesWritten(), and
> waitForDisconnected() which blocks until the operation is complete or
> the timeout expires.". In fact, I can imagine that the gnuplot inboard
> driver is perhaps precisely the kind of programs that the Qt developers
> had in mind when they wrote this sentence: a program that cannot run a
> Qt event loop because it implements its own event loop, but that still
> wants to send messages to another auxiliary program that runs a Qt event
> loop to manage a GUI.

Yes, probably so.  I read the documentation about the event loop in some 
of these socket functions.


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


> To my knowledge, here are the issues that arose on non Linux platform:
> - OSX: in the past, there was no gnuplot_qt independent process, and the
> GUI was rather managed in a thread. As you point out, this is not
> supported in Qt, and while it kind of happened to work with Linux, it
> failed on OSX.

Yes, that's not right.


> - OSX: currently, the QtGnuplotWidget has a hard time to resize itself
> to the correct size, but it is specific to the gnuplot_qt outboard driver.

I thought Mojca said gnuplot Qt term on OSX is failing to run.


> - All platforms: waitForConnected() immediatly returns if not socket is
> found (in particular, this happens when the gnuplot_qt program is still
> being initialized), even when a timeout is set. This was solved by
> introducing a custom timeout mechanism, but could more elegantly be
> solved by some communication mechanism between gnuplot ("inboard") and
> gnuplot_qt ("outboard"). I can see that part of your code actually
> implements this.

Correct.  That custom timeout is bad.


> Concerning QApplication vs. QCoreApplication & font metrics:
> Until recently, the inboard driver (qt_term.cpp) used to instantiate a
> QApplication to determine the font metrics (no event loop was required
> for this though, and more generally, no Qt event loop, nor Qt event
> based mechanism has ever been running in the main gnuplot thread). As
> Ethan said, this mechanism has been moved to the "outboard" gnuplot_qt
> program, and now the inboard driver only instantiate a QCoreApplication
> (which, as I said above, even turns out not to be necessary in practice,
> although the Qt documentation does not certify this point). The
> motivation for this was a significant performance increase: the
> initialization of a QApplication requires more than 0.5 s against a few
> 10ms for a QCoreApplication. Moving back the font metric business in the
> main gnuplot program will require to instantiate again a QApplication
> and thus cancel this performance improvement.

The 0.5 s happened every time a new Qt window is opened?


> Concerning the code you propose: apart from the synchronization problems
> between the Qt event loop and the main thread that you mention, I am
> worried about the performances. As far as I can see, the communication
> between the main thread and the thread running the Qt event loop relies
> on the signal/slot mechanism, which I think can be significantly slower
> that direct function calls. From rough testing, plotting a graph with a
> million points takes about 3x more time with the code you posted.

It will be a performance loss, yes.  I can't see it being 3x, though, if 
I were to iron out some things.  OK, so just a couple points:

1) Mojca reports the trial-and-error code I sent runs similar to what 
I'm seeing.  So we know we should be able to achieve platform independence.

2) I think the thing we agree on is that the way the QProcess is created 
and the way the link is established to gnuplot_qt isn't very good.  That 
while-loop approach shouldn't be needed.

So, how about as a first step this weekend I take just the QProcess 
startup code and make a nice diff/patch for you to try out and tweak how 
you see fit.  We'll see if that much gets us to a functioning OSX Qt 
terminal.  Simplifying that should clear things up so that if OSX Qt 
term still doesn't function we might find the source of the problem.

If it turns out that an event loop issue is a source of problem, we can 
probably split the API into those that do and don't need an event loop. 
  For example, I doubt the critical slowdown for the 1 M point example 
you cite needs to use signal/slots and can go directly to the socket. 
It's probably one move after another.  But just speculation.  First 
let's tackle the comm-link code.

Dan