gnuplot-beta

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

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

Hi,

I tried to test gnuplot with Qt5, but there is one flaw in the
configure script: I need to have pkg-config installed if I want to
build with Qt 5 even if I provide QT_CFLAGS and QT_LIBS.

I have pkg-config and lots of other libraries installed via MacPorts,
but MacPorts doesn't provide Qt5. The problem is that as soon as any
given library (like libpng, libreadline, ...) comes from MacPorts that
means that -I/path/to/macports/include and -L/path/to/macports/lib
will consequently also pick Qt4 headers and libraries from MacPorts
instead of taking them from the location specified by QT_CFLAGS and
QT_LIBS, so I need to either uninstall Qt 4 from MacPorts or remove
any dependency on MacPorts.

But if I remove MacPorts from PATH completely, gnuplot refuses to
include Qt due to lack of pkg-config:

checking for QT... configure: WARNING:
The pkg-config script could not be found or is too old.  Make sure it
is in your PATH or set the PKG_CONFIG environment variable to the full
path to pkg-config.

Alternatively, you may set the environment variables QT_CFLAGS
and QT_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

To get pkg-config, see <http://www.freedesktop.org/software/pkgconfig>.
checking for QT... configure: WARNING:
The pkg-config script could not be found or is too old.  Make sure it
is in your PATH or set the PKG_CONFIG environment variable to the full
path to pkg-config.

Alternatively, you may set the environment variables QT_CFLAGS
and QT_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

To get pkg-config, see <http://www.freedesktop.org/software/pkgconfig>.
configure: WARNING: The Qt terminal will not be compiled.
checking that generated files are newer than configure... done


Can the configure script please be changed in such a way that
pkg-config becomes optional in the case of Qt (5)? I don't have any
simple patch ready for that, but you can see below what I needed apart
from hacking the ./configure[.in] just to get a rough idea.


There is a chance that I've screwed something up (or that there are
problems with the repository I'm using), but gnuplot with Qt 5 seems
pretty nonfunctional on Mac OS X.

It starts with

> plot sin(x)
QIODevice::write: device not open
QIODevice::write: device not open
Error: short read from gnuplot_qt socket

then nevertheress plots something, but uses the wrong dimensions and
doesn't allocate any space for fonts. The second plot works better and
uses proper dimensions (I can send screenshots if anyone is
interested). The third plot throws:

qt_processTermEvent received a GE_fontprops event. This should not have happened

Mouse events (increasing or decreasing the window) don't work at all.
Or rather: they do work in a weird way. If I try to move the second
plot around, the second plot isn't changed, but the third plot is
moved. If I increase or decrease the window, the plot doesn't change,
but the next plot adapts to those dimensions.

If I type "quit" to fast (soon after the first plot), the following is thrown:

> Event not swallowed ! 1041
############### WRONG readEvent  0 6851

I'm sorry for not testing Qt 5 earlier, but it's relatively
non-trivial to figure out how to build gnuplot against Qt 5.2 on Mac.
Here is what I eventually used:

export QT_PATH=/path/to/qt/5.2.1/clang_64

export QT_LIBS="-F$QT_PATH/lib \
-framework QtCore \
-framework QtGui \
-framework QtWidgets \
-framework QtNetwork \
-framework QtSvg \
-framework QtPrintSupport"

# NOTE: CFLAGS usually look more like
#     -framework QtCore,
# but then it would need to be used as
#     #include <QtCore/QtCore>
#
# Current use of headers requires the weird
# -I$QT_PATH/lib/QtCore.framework/Headers

export QT_CFLAGS="-F$QT_PATH/lib \
-I$QT_PATH/lib/QtCore.framework/Headers \
-I$QT_PATH/lib/QtGui.framework/Headers \
-I$QT_PATH/lib/QtWidgets.framework/Headers \
-I$QT_PATH/lib/QtNetwork.framework/Headers \
-I$QT_PATH/lib/QtSvg.framework/Headers"

export UIC=$QT_PATH/bin/uic
export MOC=$QT_PATH/bin/moc
export RCC=$QT_PATH/bin/rcc

export CC=clang
export CXX=clang++

export EMACS=no

export PATH=/usr/bin:/bin:/usr/sbin:/sbin

./configure --with-qt --prefix=$PWD/inst


I can test the latest released version to see how that behaves, but it
would be of enormous help when testing numerous patches if the
repository was using some other version control system. I'm unable to
work with CVS and I have a somewhat screwed-up GIT mirror (thanks to
bugs in "git cvsimport"). Combined with all other problems related to
non-trivial Qt5 configuration ... there are simply a lot of obstacles
preventing easy testing.

I will compare the results with the released version (with branch 4.6)
next, but really ... it would help me a lot if conversion to git was
done prior to that.

Thank you,
    Mojca

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

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

On Mon, Feb 24, 2014 at 7:01 PM, Mojca Miklavec wrote:
>
> I will compare the results with the released version (with branch 4.6)

Which fails to compile (apart from similar problems related to missing
pkg-config).

../../src/qtterminal/qt_term.cpp:137:19: error: no member named
'toAscii' in 'QString'
                execlp(filename.toAscii().data(), "gnuplot_qt", (char*)NULL);
                       ~~~~~~~~ ^
../../src/qtterminal/qt_term.cpp:138:56: error: no member named
'toAscii' in 'QString'
                fprintf(stderr, "Expected Qt driver: %s\n",
filename.toAscii().data());
                                                            ~~~~~~~~ ^
../../src/qtterminal/qt_term.cpp:308:34: error: allocation of
incomplete type 'QApplication'
        QApplication* application = new QApplication(argc, (char**)( NULL));
                                        ^~~~~~~~~~~~
/path/to/qt/5.2.1/clang_64/lib/QtCore.framework/Headers/qobject.h:457:18:
note: forward declaration of 'QApplication'
    friend class QApplication;
                 ^
3 errors generated.


After fixing this one way too many other compile errors are thrown, so
I didn't even attempt to proceed.

Mojca

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

[Ethan A M. <merritt@u.washington.edu>]

On Monday, 24 February, 2014 19:23:00 Mojca Miklavec wrote:
> On Mon, Feb 24, 2014 at 7:01 PM, Mojca Miklavec wrote:
> >
> > I will compare the results with the released version (with branch 4.6)

The modifications to allow building with Qt5 are only in 4.7, not in 4.6

	Ethan



> Which fails to compile (apart from similar problems related to missing
> pkg-config).
> 
> ../../src/qtterminal/qt_term.cpp:137:19: error: no member named
> 'toAscii' in 'QString'
>                 execlp(filename.toAscii().data(), "gnuplot_qt", (char*)NULL);
>                        ~~~~~~~~ ^
> ../../src/qtterminal/qt_term.cpp:138:56: error: no member named
> 'toAscii' in 'QString'
>                 fprintf(stderr, "Expected Qt driver: %s\n",
> filename.toAscii().data());
>                                                             ~~~~~~~~ ^
> ../../src/qtterminal/qt_term.cpp:308:34: error: allocation of
> incomplete type 'QApplication'
>         QApplication* application = new QApplication(argc, (char**)( NULL));
>                                         ^~~~~~~~~~~~
> /path/to/qt/5.2.1/clang_64/lib/QtCore.framework/Headers/qobject.h:457:18:
> note: forward declaration of 'QApplication'
>     friend class QApplication;
>                  ^
> 3 errors generated.
> 
> 
> After fixing this one way too many other compile errors are thrown, so
> I didn't even attempt to proceed.
> 
> Mojca
> 
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

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

[Ethan A M. <sf...@us...>]

On Monday, 24 February, 2014 19:01:02 Mojca Miklavec wrote:
> Hi,
> 
> I tried to test gnuplot with Qt5, but there is one flaw in the
> configure script: I need to have pkg-config installed if I want to
> build with Qt 5 even if I provide QT_CFLAGS and QT_LIBS.
> 
> I have pkg-config and lots of other libraries installed via MacPorts,
> but MacPorts doesn't provide Qt5. The problem is that as soon as any
> given library (like libpng, libreadline, ...) comes from MacPorts that
> means that -I/path/to/macports/include and -L/path/to/macports/lib
> will consequently also pick Qt4 headers and libraries from MacPorts
> instead of taking them from the location specified by QT_CFLAGS and
> QT_LIBS, so I need to either uninstall Qt 4 from MacPorts or remove
> any dependency on MacPorts.

That doesn't follow.  The situation is the same on linux in the sense
that whichever Qt version is found first will be used by default.
On my machines qt5 is found before qt4 if both are present.
You can override this by
  ./configure --with-qt=qt4

If you like, I can add a similar configure option --with-qt=qt5
but alternatively you can just make sure that the qt5 directories come 
before the MacPorts/qt4 directories in your various path statements.

	Ethan


> 
> But if I remove MacPorts from PATH completely, gnuplot refuses to
> include Qt due to lack of pkg-config:
> 
> checking for QT... configure: WARNING:
> The pkg-config script could not be found or is too old.  Make sure it
> is in your PATH or set the PKG_CONFIG environment variable to the full
> path to pkg-config.
> 
> Alternatively, you may set the environment variables QT_CFLAGS
> and QT_LIBS to avoid the need to call pkg-config.
> See the pkg-config man page for more details.
> 
> To get pkg-config, see <http://www.freedesktop.org/software/pkgconfig>.
> checking for QT... configure: WARNING:
> The pkg-config script could not be found or is too old.  Make sure it
> is in your PATH or set the PKG_CONFIG environment variable to the full
> path to pkg-config.
> 
> Alternatively, you may set the environment variables QT_CFLAGS
> and QT_LIBS to avoid the need to call pkg-config.
> See the pkg-config man page for more details.
> 
> To get pkg-config, see <http://www.freedesktop.org/software/pkgconfig>.
> configure: WARNING: The Qt terminal will not be compiled.
> checking that generated files are newer than configure... done
> 
> 
> Can the configure script please be changed in such a way that
> pkg-config becomes optional in the case of Qt (5)? I don't have any
> simple patch ready for that, but you can see below what I needed apart
> from hacking the ./configure[.in] just to get a rough idea.
> 
> 
> There is a chance that I've screwed something up (or that there are
> problems with the repository I'm using), but gnuplot with Qt 5 seems
> pretty nonfunctional on Mac OS X.
> 
> It starts with
> 
> > plot sin(x)
> QIODevice::write: device not open
> QIODevice::write: device not open
> Error: short read from gnuplot_qt socket
> 
> then nevertheress plots something, but uses the wrong dimensions and
> doesn't allocate any space for fonts. The second plot works better and
> uses proper dimensions (I can send screenshots if anyone is
> interested). The third plot throws:
> 
> qt_processTermEvent received a GE_fontprops event. This should not have happened
> 
> Mouse events (increasing or decreasing the window) don't work at all.
> Or rather: they do work in a weird way. If I try to move the second
> plot around, the second plot isn't changed, but the third plot is
> moved. If I increase or decrease the window, the plot doesn't change,
> but the next plot adapts to those dimensions.
> 
> If I type "quit" to fast (soon after the first plot), the following is thrown:
> 
> > Event not swallowed ! 1041
> ############### WRONG readEvent  0 6851
> 
> I'm sorry for not testing Qt 5 earlier, but it's relatively
> non-trivial to figure out how to build gnuplot against Qt 5.2 on Mac.
> Here is what I eventually used:
> 
> export QT_PATH=/path/to/qt/5.2.1/clang_64
> 
> export QT_LIBS="-F$QT_PATH/lib \
> -framework QtCore \
> -framework QtGui \
> -framework QtWidgets \
> -framework QtNetwork \
> -framework QtSvg \
> -framework QtPrintSupport"
> 
> # NOTE: CFLAGS usually look more like
> #     -framework QtCore,
> # but then it would need to be used as
> #     #include <QtCore/QtCore>
> #
> # Current use of headers requires the weird
> # -I$QT_PATH/lib/QtCore.framework/Headers
> 
> export QT_CFLAGS="-F$QT_PATH/lib \
> -I$QT_PATH/lib/QtCore.framework/Headers \
> -I$QT_PATH/lib/QtGui.framework/Headers \
> -I$QT_PATH/lib/QtWidgets.framework/Headers \
> -I$QT_PATH/lib/QtNetwork.framework/Headers \
> -I$QT_PATH/lib/QtSvg.framework/Headers"
> 
> export UIC=$QT_PATH/bin/uic
> export MOC=$QT_PATH/bin/moc
> export RCC=$QT_PATH/bin/rcc
> 
> export CC=clang
> export CXX=clang++
> 
> export EMACS=no
> 
> export PATH=/usr/bin:/bin:/usr/sbin:/sbin
> 
> ./configure --with-qt --prefix=$PWD/inst
> 
> 
> I can test the latest released version to see how that behaves, but it
> would be of enormous help when testing numerous patches if the
> repository was using some other version control system. I'm unable to
> work with CVS and I have a somewhat screwed-up GIT mirror (thanks to
> bugs in "git cvsimport"). Combined with all other problems related to
> non-trivial Qt5 configuration ... there are simply a lot of obstacles
> preventing easy testing.
> 
> I will compare the results with the released version (with branch 4.6)
> next, but really ... it would help me a lot if conversion to git was
> done prior to that.
> 
> Thank you,
>     Mojca
> 
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

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

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

On Mon, Feb 24, 2014 at 7:25 PM, Ethan A Merritt wrote:
> On Monday, 24 February, 2014 19:01:02 Mojca Miklavec wrote:
>> Hi,
>>
>> I tried to test gnuplot with Qt5, but there is one flaw in the
>> configure script: I need to have pkg-config installed if I want to
>> build with Qt 5 even if I provide QT_CFLAGS and QT_LIBS.
>>
>> I have pkg-config and lots of other libraries installed via MacPorts,
>> but MacPorts doesn't provide Qt5. The problem is that as soon as any
>> given library (like libpng, libreadline, ...) comes from MacPorts that
>> means that -I/path/to/macports/include and -L/path/to/macports/lib
>> will consequently also pick Qt4 headers and libraries from MacPorts
>> instead of taking them from the location specified by QT_CFLAGS and
>> QT_LIBS, so I need to either uninstall Qt 4 from MacPorts or remove
>> any dependency on MacPorts.
>
> That doesn't follow.  The situation is the same on linux in the sense
> that whichever Qt version is found first will be used by default.

The problem is that -I/opt/local/include seems to be the first
argument to compiler "no matter what". I inspected the Makefiles a bit
and it seems that this is set by CPPFLAGS. I'm not exactly sure what
sets it, but the workaround seems to be to set
    export INCLUDES="$QT_CFLAGS"
which puts the paths to Qt5 in front of everything else. Without that,
Qt4 is always found first.

Despite this, I still believe that configuration should work properly
when pkg-config is absent.

Weird enough, after I have compiled gnuplot in a slightly different
way (without excluding MacPorts libraries, but maybe only the timing
has changed), I get

gnuplot> plot sin(x)
QIODevice::write: device not open
QIODevice::write: device not open
Error: short read from gnuplot_qt socket
gnuplot> qt_processTermEvent received a GE_fontprops event. This
should not have happened

gnuplot> plot sin(x)

but the mouse events work. The first plot is still very weird with
wrong font initializations. Something is still misbehaving.

Mojca

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

[Ethan A M. <sf...@us...>]

On Monday, 24 February, 2014 20:28:05 Mojca Miklavec wrote:
> On Mon, Feb 24, 2014 at 7:25 PM, Ethan A Merritt wrote:
> 
> The problem is that -I/opt/local/include seems to be the first
> argument to compiler "no matter what". I inspected the Makefiles a bit
> and it seems that this is set by CPPFLAGS. I'm not exactly sure what
> sets it, but the workaround seems to be to set
>     export INCLUDES="$QT_CFLAGS"
> which puts the paths to Qt5 in front of everything else. Without that,
> Qt4 is always found first.
> 
> Despite this, I still believe that configuration should work properly
> when pkg-config is absent.
> 
> Weird enough, after I have compiled gnuplot in a slightly different
> way (without excluding MacPorts libraries, but maybe only the timing
> has changed), I get
> 
> gnuplot> plot sin(x)
> QIODevice::write: device not open
> QIODevice::write: device not open

I get those messages also.  They seem to be harmless.

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

But that, as it self-declares, should not happen.
Let me think about what it might mean. 

> gnuplot> plot sin(x)
> 
> but the mouse events work. The first plot is still very weird with
> wrong font initializations.

That is consistent with the error message you showed.
The font metrics information for the first plot was apparently 
delivered to the wrong recipient and/or at the wrong time.

	Ethan

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

[Ethan A M. <sf...@us...>]

On Monday, 24 February, 2014 20:28:05 Mojca Miklavec wrote:
> Despite this, I still believe that configuration should work properly
> when pkg-config is absent.

I seem to recall that we have had this discussion before.
pkg-config is just a tool that sets various paths and definitions.
If it is not present you can still set those paths and definitions yourself.
The warnings emitted by ./configure about not finding a pkg-config
file are just informational, not fatal errors.

For example, libcerf has no *.pc file so ./configure reports

%%%%
Package requirements (libcerf) were not met:
No package 'libcerf' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables LIBCERF_CFLAGS
and LIBCERF_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
%%%%

But in fact none of that is needed because libcerf.so is installed in
a standard system location and is found automatically and included
in the gnuplot build despite being unknown to pkg-config.

Now if you are saying that the PKG_CHECK_MODULES macro
itself is problematic, then I suppose you can add it as a null operation
in m4/apple.m4


	Ethan

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

[Bastian M. <bma...@we...>]

Am 24.02.2014 20:39, schrieb Ethan A Merritt:
> On Monday, 24 February, 2014 20:28:05 Mojca Miklavec wrote:
>> On Mon, Feb 24, 2014 at 7:25 PM, Ethan A Merritt wrote:
>>
>> The problem is that -I/opt/local/include seems to be the first
>> argument to compiler "no matter what". I inspected the Makefiles a bit
>> and it seems that this is set by CPPFLAGS. I'm not exactly sure what
>> sets it, but the workaround seems to be to set
>>      export INCLUDES="$QT_CFLAGS"
>> which puts the paths to Qt5 in front of everything else. Without that,
>> Qt4 is always found first.
>>
>> Despite this, I still believe that configuration should work properly
>> when pkg-config is absent.
>>
>> Weird enough, after I have compiled gnuplot in a slightly different
>> way (without excluding MacPorts libraries, but maybe only the timing
>> has changed), I get
>>
>> gnuplot> plot sin(x)
>> QIODevice::write: device not open
>> QIODevice::write: device not open

The reason for these is the section below in qt_graphics(). The first 
time it is called the qt->socket is not yet open and thus the call to 
qt_flushOutBuffer will fail:

	qt->out << GEDesactivate;
	qt_flushOutBuffer();
	qt_connectToServer();

Adding this snippet to qt_flushOutBuffer() solves that problem:

	if (!qt || !qt->socket.isValid())
		return;

But maybe the order of commands in qt_graphics() should be changed instead.

   Bastian

>
> I get those messages also.  They seem to be harmless.
>
>> Error: short read from gnuplot_qt socket
>> gnuplot> qt_processTermEvent received a GE_fontprops event. This
>> should not have happened
>
> But that, as it self-declares, should not happen.
> Let me think about what it might mean.
>
>> gnuplot> plot sin(x)
>>
>> but the mouse events work. The first plot is still very weird with
>> wrong font initializations.
>
> That is consistent with the error message you showed.
> The font metrics information for the first plot was apparently
> delivered to the wrong recipient and/or at the wrong time.
>
> 	Ethan
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

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

[Ethan A M. <sf...@us...>]

On Monday, 24 February, 2014 21:12:17 Bastian Märkisch wrote:
> >> gnuplot> plot sin(x)
> >> QIODevice::write: device not open
> >> QIODevice::write: device not open
> 
> The reason for these is the section below in qt_graphics(). The first 
> time it is called the qt->socket is not yet open and thus the call to 
> qt_flushOutBuffer will fail:
> 
>         qt->out << GEDesactivate;
>         qt_flushOutBuffer();
>         qt_connectToServer();
> 
> Adding this snippet to qt_flushOutBuffer() solves that problem:
> 
>         if (!qt || !qt->socket.isValid())
>                 return;
> 
> But maybe the order of commands in qt_graphics() should be changed instead.

I think the order is correct.  It wants to flush and close any previous
connection before starting a new one.   The message comes when
there was no previous connection.  

Curiously, I see these warnings on some machines but not others.
I've no idea why.  But your check in qt_flushOutBuffer() looks correct.
	
	Ethan

>    Bastian
> 

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

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

On Mon, Feb 24, 2014 at 9:12 PM, Bastian Märkisch <bma...@we...> wrote:
> Am 24.02.2014 20:39, schrieb Ethan A Merritt:
>> On Monday, 24 February, 2014 20:28:05 Mojca Miklavec wrote:
>>> On Mon, Feb 24, 2014 at 7:25 PM, Ethan A Merritt wrote:
>>>
>>> The problem is that -I/opt/local/include seems to be the first
>>> argument to compiler "no matter what". I inspected the Makefiles a bit
>>> and it seems that this is set by CPPFLAGS. I'm not exactly sure what
>>> sets it, but the workaround seems to be to set
>>>      export INCLUDES="$QT_CFLAGS"
>>> which puts the paths to Qt5 in front of everything else. Without that,
>>> Qt4 is always found first.
>>>
>>> Despite this, I still believe that configuration should work properly
>>> when pkg-config is absent.
>>>
>>> Weird enough, after I have compiled gnuplot in a slightly different
>>> way (without excluding MacPorts libraries, but maybe only the timing
>>> has changed), I get
>>>
>>> gnuplot> plot sin(x)
>>> QIODevice::write: device not open
>>> QIODevice::write: device not open
>
> Adding this snippet to qt_flushOutBuffer() solves that problem:
>
>         if (!qt || !qt->socket.isValid())
>                 return;

This avoids the QIODevice warnings/errors. But in general I still get either

Terminal type set to 'qt'
gnuplot> plot sin(x)
Error: short read from gnuplot_qt socket
gnuplot> quit
$ Event not swallowed ! 1041
############### WRONG readEvent  0 6851

or

Terminal type set to 'qt'
gnuplot> plot sin(x)
Error: short read from gnuplot_qt socket
gnuplot> qt_processTermEvent received a GE_fontprops event. This
should not have happened

gnuplot> plot sin(x)

depending on how much I wait before quitting.

Mojca

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

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

On Mon, Feb 24, 2014 at 8:54 PM, Ethan A Merritt wrote:
> On Monday, 24 February, 2014 20:28:05 Mojca Miklavec wrote:
>> Despite this, I still believe that configuration should work properly
>> when pkg-config is absent.
>
> I seem to recall that we have had this discussion before.
> pkg-config is just a tool that sets various paths and definitions.
> If it is not present you can still set those paths and definitions yourself.

Except that it doesn't work in case of Qt 5.

> The warnings emitted by ./configure about not finding a pkg-config
> file are just informational, not fatal errors.

They are not fatal, but in case of Qt 5 there is no way to enable the
Qt terminal without a working pkg-config.

> For example, libcerf has no *.pc file so ./configure reports
>
> %%%%
> Package requirements (libcerf) were not met:
> No package 'libcerf' found
> Consider adjusting the PKG_CONFIG_PATH environment variable if you
> installed software in a non-standard prefix.
> Alternatively, you may set the environment variables LIBCERF_CFLAGS
> and LIBCERF_LIBS to avoid the need to call pkg-config.
> See the pkg-config man page for more details.
> %%%%
>
> But in fact none of that is needed because libcerf.so is installed in
> a standard system location and is found automatically and included
> in the gnuplot build despite being unknown to pkg-config.
>
> Now if you are saying that the PKG_CHECK_MODULES macro
> itself is problematic, then I suppose you can add it as a null operation
> in m4/apple.m4

No, I'm not saying that PKG_CHECK_MODULES macro is problematic. All
I'm saying is that the logic in configure.in is wrong for Qt in case
of missing pkg-configure.

If pkg-config is missing, configure sets
    enable_qt_ok=yes
    try_qt4=yes
Because
    PKG_CHECK_MODULES_NOFAIL(QT, [Qt5Core Qt5Gui Qt5Network Qt5Svg
Qt5PrintSupport])
fails, it doesn't set "try_qt4=no", so the code happily continues in
    if test ${try_qt4} != no; then
The code
    PKG_CHECK_MODULES_NOFAIL(QT, [QtCore >= 4.5 QtGui >= 4.5 QtNetwork
>= 4.5 QtSvg >= 4.5])
fails again and then
    if test $pkg_failed != no; then
        enable_qt_ok=no
        AC_MSG_WARN([The Qt terminal will not be compiled.])
is happily executed and the Qt terminal gets disabled.

So in contrast to libcerf or any other library, missing pkg-config
currently doesn't allow compilation of the Qt terminal at all.

Disabling pkg-config for all Apples seems unreasonable because some
machines (using MacPorts, HomeBrew or Fink) do provide it. Also, there
exists a folder <QTDIR5>/lib/pkgconfig, but setting PKG_CONFIG_PATH
alone doesn't help in case of existing Qt 4 in MacPorts/Fink and
compiling gnuplot without MacPorts/Fink/HomeBrew is a bit of a pain
anyway.

(Maybe --with-qt=qt5 would help after all if you need to know which
version of Qt is being used when pkg-config is missing, but I leave
that to you. I would imagine that an argument to --with-qt would be
something like --with-qt=/path/to/qtdir5 anyway.)

Mojca

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

[Ethan A M. <sf...@us...>]

I've added an option ./configure --with-qt=qt5
that will forcibly try to build with qt5 rather than falling back to trying qt4
and possibly failing.

	Ethan

On Monday, 24 February, 2014 21:38:20 Mojca Miklavec wrote:
> On Mon, Feb 24, 2014 at 8:54 PM, Ethan A Merritt wrote:
> > On Monday, 24 February, 2014 20:28:05 Mojca Miklavec wrote:
> >> Despite this, I still believe that configuration should work properly
> >> when pkg-config is absent.
> >
> > I seem to recall that we have had this discussion before.
> > pkg-config is just a tool that sets various paths and definitions.
> > If it is not present you can still set those paths and definitions yourself.
> 
> Except that it doesn't work in case of Qt 5.
> 
> > The warnings emitted by ./configure about not finding a pkg-config
> > file are just informational, not fatal errors.
> 
> They are not fatal, but in case of Qt 5 there is no way to enable the
> Qt terminal without a working pkg-config.
> 
> > For example, libcerf has no *.pc file so ./configure reports
> >
> > %%%%
> > Package requirements (libcerf) were not met:
> > No package 'libcerf' found
> > Consider adjusting the PKG_CONFIG_PATH environment variable if you
> > installed software in a non-standard prefix.
> > Alternatively, you may set the environment variables LIBCERF_CFLAGS
> > and LIBCERF_LIBS to avoid the need to call pkg-config.
> > See the pkg-config man page for more details.
> > %%%%
> >
> > But in fact none of that is needed because libcerf.so is installed in
> > a standard system location and is found automatically and included
> > in the gnuplot build despite being unknown to pkg-config.
> >
> > Now if you are saying that the PKG_CHECK_MODULES macro
> > itself is problematic, then I suppose you can add it as a null operation
> > in m4/apple.m4
> 
> No, I'm not saying that PKG_CHECK_MODULES macro is problematic. All
> I'm saying is that the logic in configure.in is wrong for Qt in case
> of missing pkg-configure.
> 
> If pkg-config is missing, configure sets
>     enable_qt_ok=yes
>     try_qt4=yes
> Because
>     PKG_CHECK_MODULES_NOFAIL(QT, [Qt5Core Qt5Gui Qt5Network Qt5Svg
> Qt5PrintSupport])
> fails, it doesn't set "try_qt4=no", so the code happily continues in
>     if test ${try_qt4} != no; then
> The code
>     PKG_CHECK_MODULES_NOFAIL(QT, [QtCore >= 4.5 QtGui >= 4.5 QtNetwork
> >= 4.5 QtSvg >= 4.5])
> fails again and then
>     if test $pkg_failed != no; then
>         enable_qt_ok=no
>         AC_MSG_WARN([The Qt terminal will not be compiled.])
> is happily executed and the Qt terminal gets disabled.
> 
> So in contrast to libcerf or any other library, missing pkg-config
> currently doesn't allow compilation of the Qt terminal at all.
> 
> Disabling pkg-config for all Apples seems unreasonable because some
> machines (using MacPorts, HomeBrew or Fink) do provide it. Also, there
> exists a folder <QTDIR5>/lib/pkgconfig, but setting PKG_CONFIG_PATH
> alone doesn't help in case of existing Qt 4 in MacPorts/Fink and
> compiling gnuplot without MacPorts/Fink/HomeBrew is a bit of a pain
> anyway.
> 
> (Maybe --with-qt=qt5 would help after all if you need to know which
> version of Qt is being used when pkg-config is missing, but I leave
> that to you. I would imagine that an argument to --with-qt would be
> something like --with-qt=/path/to/qtdir5 anyway.)
> 
> Mojca
> 
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

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

[sfeam <sf...@us...>]

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.

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

These don't really seem to be gnuplot problems at all,
so I suggest you hunt around to see what other OSX users are
reporting about font problems.  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.

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 and read it in again at the start
of the next session.  Then you would hit this lethargic system
response only when you requested a never-used-before font.

Maintaining a private font cache would be wasted effort on
linux, but if you want to code up something for OSX-only
inclusion go right ahead.

	Ethan

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

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

[Ethan A M. <sf...@us...>]

On Wednesday, 26 February, 2014 09:24:37 Mojca Miklavec wrote:
> 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.

OK, I have applied that first patch for #ifdef Q_OS_MAC only.

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

When you say "after closing gnuplot_qt", do you mean closing the
window, or do you mean killing the process? 
Simply closing the window should not have much effect; the program will
reopen the window as needed.   Killing the process does indeed trigger
that 30 second timeout.   A fix for that is also now in cvs.

	Ethan

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 9:54 PM, Ethan A Merritt wrote:
> On Wednesday, 26 February, 2014 09:24:37 Mojca Miklavec wrote:
>> 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.
>
> OK, I have applied that first patch for #ifdef Q_OS_MAC only.

Thank you, it works fine now. But is it on purpose that every mac/qt5
user will now get the following printed?

Terminal type set to 'qt'
gnuplot> plot cos(x)
Error: short read from gnuplot_qt socket while expecting font metrics
Error: short read from gnuplot_qt socket while expecting font metrics
gnuplot>

>> 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.
>
> When you say "after closing gnuplot_qt", do you mean closing the
> window, or do you mean killing the process?

Killing it (= right mouse click -> Quit). I'm sorry for not being exact.

> Simply closing the window should not have much effect; the program will
> reopen the window as needed.

Indeed.

> Killing the process does indeed trigger
> that 30 second timeout.   A fix for that is also now in cvs.

Great, thank you. It works as expected now.

Thanks a lot for fixing all the issues and making Qt work again on Macs.

-------------------

Among the remaining "visible flaws" only those come to my mind now:

- the first plot gets too small window and the lower part of the plot
is not visible; the difference is exactly the status bar; the second
plot gets resized and gets the proper size; curiously enough this is
now a problem with both Qt 4 and Qt 5 and must have been introduced
with one of the recent changes (when I last tested only the reported
size was changed, but there was no visible effect)

- the default font is way too small; on my 13" notebook the numbers
are only 1,5 mm high (7 pixels); I don't know the reason, but on wxt
the font looks a lot better; maybe I should test a simple Qt
application to see what defaults it uses

- horizontal scrolling goes in the wrong direction since a while (and
scrolling is way too fast for precise trackpads) – but both "problems"
are present in other terminals as well

- in Qt 5 the application doesn't show any icon (I already
investigated a while back without luck) – that's just cosmetics though
and doesn't hurt functionality in any way

Mojca

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

[Allin C. <cot...@wf...>]

On Wed, 26 Feb 2014, Mojca Miklavec wrote:

> On Wed, Feb 26, 2014 at 9:54 PM, Ethan A Merritt wrote:
>> On Wednesday, 26 February, 2014 09:24:37 Mojca Miklavec wrote:
>>> 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.
>>
>> OK, I have applied that first patch for #ifdef Q_OS_MAC only.
>
> Thank you, it works fine now. But is it on purpose that every mac/qt5
> user will now get the following printed?
>
> Terminal type set to 'qt'
> gnuplot> plot cos(x)
> Error: short read from gnuplot_qt socket while expecting font metrics
> Error: short read from gnuplot_qt socket while expecting font metrics
> gnuplot>

Yes, because users of qt5 on Macs are a big nuisance and deserve to 
be punished. Not.

What do you think? Maybe it has to do with debugging? If, perchance, 
that might be needed ;-)

Allin Cottrell

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

[Ethan A M. <sf...@us...>]

On Wednesday, 26 February, 2014 18:04:14 Allin Cottrell wrote:
> On Wed, 26 Feb 2014, Mojca Miklavec wrote:
> 
> > On Wed, Feb 26, 2014 at 9:54 PM, Ethan A Merritt wrote:
> >> On Wednesday, 26 February, 2014 09:24:37 Mojca Miklavec wrote:
> >>> 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.
> >>
> >> OK, I have applied that first patch for #ifdef Q_OS_MAC only.
> >
> > Thank you, it works fine now. But is it on purpose that every mac/qt5
> > user will now get the following printed?
> >
> > Terminal type set to 'qt'
> > gnuplot> plot cos(x)
> > Error: short read from gnuplot_qt socket while expecting font metrics
> > Error: short read from gnuplot_qt socket while expecting font metrics
> > gnuplot>
> 
> Yes, because users of qt5 on Macs are a big nuisance and deserve to 
> be punished. Not.
> 
> What do you think? Maybe it has to do with debugging? If, perchance, 
> that might be needed ;-)

All of the qDebug() messages are of the "this is not supposed to happen"
variety.  The one above does not trigger on windows or linux, and if I
understand correctly does not trigger on OSX with Qt4 either.   Whether
it points to a problem with Qt5 per se or to a larger problem with OSX
font handling I do not know, but either way it really is fingering a fixable
problem.  If nothing else it should allow OSX users to diagnose
semi-quantitatively whether tweaks to their font setup improve or degrade
the performance.

	Ethan