Re: Building with Qt depends on pkg-config, Qt 5 term doesn't work on OS X

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

On Wed, Feb 26, 2014 at 6:13 AM, sfeam wrote:
> On Tuesday, 25 February 2014 10:36:59 PM Mojca Miklavec wrote:
>> I now also tested with Qt4. Qt 4 doesn't print that long list of
>> errors and starts instantly (as opposed to Qt 5).
>>
>> But if I exit the Qt window and plot again, it now also takes about 30
>> seconds to plot a new window.
>>
>> Mojca
>
> So if I understand correctly, OSX + Qt4 is now working correctly
> except for a problem with font intialization elsewhere in the system.

I believe Qt 4 has worked properly for a couple of days.

Font initialization is only a problem on Qt 5.


I thought I had problems with font initialization in Qt 4, but it
turned out that when I quit gnuplot_qt, gnuplot was merely waiting for
30 seconds for this timeout:
    QDateTime timeout = QDateTime::currentDateTime().addMSecs(30000);

> OSX_+ Qt5 has at least the same problem with font initialization and
> possibly an additional delay before the first plot.

Only Qt 5 is throwing

Error: short read from gnuplot_qt socket while expecting font metrics
Error: short read from gnuplot_qt socket while expecting font metrics
Error: short read from gnuplot_qt socket while expecting font metrics
gnuplot> qt_processTermEvent received a GE_fontprops event. This
should not have happened

and is having problems with font metrics without your patch (sent
off-list). Qt 4 works fine already for the first plot.

> These don't really seem to be gnuplot problems at all,

That 30 second delay *is* a gnuplot "problem".

> so I suggest you hunt around to see what other OSX users are
> reporting about font problems.

I don't know if I have any Qt 5-based application on my system, but I
don't remember any other program having that problem. I remember
loooooong starting times of wxWidgets terminal in gnuplot on windows
when fc-cache was being run (similar for mplayer, vlc player and a
couple of other programs).

> I found a couple of reports
> that say OSX has a problem with large numbers of installed fonts,
> and the only solution they offered was to uninstall as many
> fonts as possible.   That sounds like a crock to me, but in any
> case it's not something we can fix in gnuplot.

After applying your first patch only the first gnuplot run took half a
minute to start. Subsequent runs take 4 seconds at most which is
totally acceptable.

Now the only long delay comes from that long timeout after closing
gnuplot_qt. Gnuplot throws "Error: short read from gnuplot_qt socket"
when I quit gnuplot_qt, so it's probably aware that gnuplot_qt is no
longer present. In such cases it could try to open a new gnuplot_qt
faster than in 30 seconds.

(I'm not saying that there are no Qt bugs introduced in Qt 5, I'm just
not sure how exactly to report them. I would probably need to send
them minimal examples reproducing the same problematic behaviour.)

> That isn't to say that no workaround is possible.
> Based on my current understanding, you could work around this
> problem entirely with Qt4 by having gnuplot save its font cache
> at the end of each qt session

There were no problems with font caching on Qt 4.

Mojca