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

[Mojca M. <moj...@gm...>]

On Fri, Feb 7, 2014 at 10:03 PM, Thomas Bleher wrote:
> * Mojca Miklavec [2014-02-07 12:37]:
>> On Fri, Feb 7, 2014 at 11:50 AM, Mojca Miklavec wrote:
>> >
>> > I wanted to test, but it seems that Qt terminal is broken on Mac now.
>>
>> The commit that broke gnuplot on Mac seems to be the following one:
>>
>> Author: sfeam <sfeam>
>> Date:   Sat Oct 26 05:44:10 2013 +0000
>>
>>     explicit construction and destruction of qt_term data
>
> Hmm, this is strange. I have no idea how this patch could have broken
> the Mac build.

Maybe it just helped a deeper problem surface now. The implementation
of the Qt terminal never really worked properly on Macs. I might be
wrong, but I would blame forking. Gnuplot starts two separate Qt
programs/windows, the proper one and a "fake/nonworking" one. Trying
to print anything crashes gnuplot (but crash during printing is not
really a showstopper) etc. On Qt 4 and Mac OS X >= 10.7 one can hide
the second fake window. On Qt 5 I have no clue how to hide it (so
users end up with two icons per running gnuplot), but at least
printing doesn't crash.

It would be great if someone could figure out how to avoid forking
(and try to avoid it at least on mac) if that is possible at all. I'm
not skilled enough to understand how gnuplot_qt and forking works to
be able to change it.

> As a short explanation: before this patch, several variables in
> qt_term.cpp were initialized statically. For types that have a
> constructor, this means that their constructor is called before main().
> The order of initialization between different files is unspecified. So
> if one constructor depends on a static field in another file that is
> also initialized by a constructor, things may crash.
> This happened on Windows, where some Qt variable was initialized before
> the Qt library itself.
>
> This patch changed the code so that all variables that depend on Qt are
> initialized only after main() has started (so at a time when Qt is
> guaranteed to have been initialized).
>
> I don't have a Mac, so I can't test anything, unfortunately.
> Two things come to mind that you could look at:
>
> - Does this happen with the newest version of Qt4? It may be a bug that
>   has already been fixed.

Yes. I'm using 4.8.5. (Unfortunately the maintainer of Qt 4 gave up on
Qt 5 for some reason – apparently too much work and too many problems
when he tried to create a package and nobody else is willing to step
in. But I did successfully link gnuplot against a different Qt
installation and I could try to repeat that now to check whether
current solution works in 5.2. But the sole fact that it fails to work
with Qt 4 makes the current situation unacceptable for a release in my
opinion.)

> - Does it work if you start gnuplot_qt manually? The qt terminal can
>   connect to already running programs. To do this:
>   - start gnuplot_qt
>   - determine its pid
>   - start gnuplot
>   - call 'set terminal qt widget "qtgnuplot<pid>"', where <pid> is
>     replaced by the numerical pid of the gnuplot_qt process
>   - Try to plot something, e.g. "plot x"

Yes, that works.

Mojca