Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2012-08-22 03:40:03
|
What is the status of the Qt terminal? It easily builds and works on linux systems. How about Apple? Has it been tried on Windows? I see in the configure files is AC_FUNC_FORK, but there doesn't appear to be any conditional code related to that in the qtterminal directory. Thanks, Dan |
|
From: Mojca M. <moj...@gm...> - 2012-08-22 07:37:52
|
On Wed, Aug 22, 2012 at 5:39 AM, Daniel J Sebald wrote: > What is the status of the Qt terminal? It easily builds and works on > linux systems. How about Apple? The trunk code finally compiles (since the patch on "2012-06-23 Jérôme lodewyck"), but it would be nice if that commit could be included in branch-4-6-stable before next release. It works automatically on (for example) MacPorts-based Qt via pkg-config. When users install Qt from official installers, it is necessary to manually specify QT_LIBS and QT_CFLAGS even though it would be easy enough to check for system-wide installation and a single extra set of flags. (There is only one official installer, so anyone using that requires the same flags.) There are some issues with forking, most annoying is that printing crashes while opening printing dialog. (If I try to circumvent the printing dialog, it prints fine.) I have no idea where to look to fix it. Two programs open on dock, but one icon gets hidden. Suboptimal, but acceptable. Overall it works nicely and Qt terminal is also available as an optional install on MacPorts. Mojca PS: Personally I would like to see the icon change (use a higher resolution at least) and there's a slightly annoying "jumping" canvas (not mac-specific) when resizing/increasing the plot area. It seems as if plot area tries to be centered and alternates between Qt moving existing plot to center of the new bigger area and gnuplot resizing the image after some time (short time interval, but long enough to generate some jumping visible.) |
|
From: Daniel J S. <dan...@ie...> - 2012-08-22 08:22:10
|
On 08/22/2012 02:37 AM, Mojca Miklavec wrote: > On Wed, Aug 22, 2012 at 5:39 AM, Daniel J Sebald wrote: >> What is the status of the Qt terminal? It easily builds and works on >> linux systems. How about Apple? > > The trunk code finally compiles (since the patch on "2012-06-23 > Jérôme lodewyck"), but it would be nice if that commit could be > included in branch-4-6-stable before next release. I assume there is a Qt init step that will check that the system has Qt support available and active. > It works automatically on (for example) MacPorts-based Qt via > pkg-config. When users install Qt from official installers, it is > necessary to manually specify QT_LIBS and QT_CFLAGS even though it > would be easy enough to check for system-wide installation and a > single extra set of flags. (There is only one official installer, so > anyone using that requires the same flags.) > > There are some issues with forking, most annoying is that printing > crashes while opening printing dialog. (If I try to circumvent the > printing dialog, it prints fine.) I have no idea where to look to fix > it. Two programs open on dock, but one icon gets hidden. Suboptimal, > but acceptable. The fork influences Qt printing? Strange. > Overall it works nicely and Qt terminal is also available as an > optional install on MacPorts. It sounds to me like Qt for Windows hasn't been tested yet. Should I seek out a volunteer? The way it appears, my guess is the fork won't compile under Windows. The wxWidgets terminal appears to conditionally deal with fork when it isn't available. > PS: Personally I would like to see the icon change (use a higher > resolution at least) and there's a slightly annoying "jumping" canvas > (not mac-specific) when resizing/increasing the plot area. It seems as > if plot area tries to be centered and alternates between Qt moving > existing plot to center of the new bigger area and gnuplot resizing > the image after some time (short time interval, but long enough to > generate some jumping visible.) I've seen that. In some cases it is too fast to tell exactly what is happening, but it is discombobulating. The last gnuplot demo is a big polygon rendering and in between renderings when resizing the window the image moves to the center temporarily. If it were to stay put then expand, it wouldn't look so bad. Perhaps there is something with rescale/no-rescale that Qt hasn't worked out exactly right. Thanks Mojca, Dan |
|
From: Mojca M. <moj...@gm...> - 2012-08-22 09:05:12
|
On Wed, Aug 22, 2012 at 10:21 AM, Daniel J Sebald wrote: > On 08/22/2012 02:37 AM, Mojca Miklavec wrote: >> >> On Wed, Aug 22, 2012 at 5:39 AM, Daniel J Sebald wrote: >>> >>> What is the status of the Qt terminal? It easily builds and works on >>> linux systems. How about Apple? >> >> >> The trunk code finally compiles (since the patch on "2012-06-23 >> Jérôme lodewyck"), but it would be nice if that commit could be >> included in branch-4-6-stable before next release. > > I assume there is a Qt init step that will check that the system has Qt > support available and active. I'm not sure if I understood the question properly. >> There are some issues with forking, most annoying is that printing >> crashes while opening printing dialog. (If I try to circumvent the >> printing dialog, it prints fine.) I have no idea where to look to fix >> it. Two programs open on dock, but one icon gets hidden. Suboptimal, >> but acceptable. > > The fork influences Qt printing? Strange. I'm not 100% sure about that, but that's the only explanation I have. It crashes here: QPrinter printer; if (QPrintDialog(&printer).exec() == QDialog::Accepted) and the same command works flawlessly if I write a simple hello world application. Also, if I skip the QPrintDialog and just print (that is: if I modify and recompile source) it starts working. It might or might not be connected with forking, but I have no clue where to look. Here's what gets printed into gnuplot screen: gnuplot_qt[69041] <Error>: kCGErrorIllegalArgument: _CGSFindSharedWindow: WID -1 gnuplot_qt[69041] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged. gnuplot_qt[69041] <Error>: kCGErrorIllegalArgument: CGSSetWindowShadowAndRimParametersWithStretch: Invalid window 0xffffffff But printing is not critical. >> PS: Personally I would like to see the icon change (use a higher >> resolution at least) and there's a slightly annoying "jumping" canvas >> (not mac-specific) when resizing/increasing the plot area. It seems as >> if plot area tries to be centered and alternates between Qt moving >> existing plot to center of the new bigger area and gnuplot resizing >> the image after some time (short time interval, but long enough to >> generate some jumping visible.) > > I've seen that. In some cases it is too fast to tell exactly what is > happening, but it is discombobulating. The last gnuplot demo is a big > polygon rendering and in between renderings when resizing the window the > image moves to the center temporarily. If it were to stay put then expand, > it wouldn't look so bad. Perhaps there is something with rescale/no-rescale > that Qt hasn't worked out exactly right. There might be some trivial setting to tell Qt to stick to left & top border rather than center the plot. Then this effect should go away. I didn't look into it yet. Mojca |
|
From: Daniel J S. <dan...@ie...> - 2012-08-22 14:10:57
|
On 08/22/2012 04:05 AM, Mojca Miklavec wrote: > On Wed, Aug 22, 2012 at 10:21 AM, Daniel J Sebald wrote: >> On 08/22/2012 02:37 AM, Mojca Miklavec wrote: >>> >>> On Wed, Aug 22, 2012 at 5:39 AM, Daniel J Sebald wrote: >>>> >>>> What is the status of the Qt terminal? It easily builds and works on >>>> linux systems. How about Apple? >>> >>> >>> The trunk code finally compiles (since the patch on "2012-06-23 >>> Jérôme lodewyck"), but it would be nice if that commit could be >>> included in branch-4-6-stable before next release. >> >> I assume there is a Qt init step that will check that the system has Qt >> support available and active. > > I'm not sure if I understood the question properly. If the Qt terminal is included with the next release and the user doesn't have Qt operational on his or her system, what will happen? That's all I meant. >>> There are some issues with forking, most annoying is that printing >>> crashes while opening printing dialog. (If I try to circumvent the >>> printing dialog, it prints fine.) I have no idea where to look to fix >>> it. Two programs open on dock, but one icon gets hidden. Suboptimal, >>> but acceptable. >> >> The fork influences Qt printing? Strange. > > I'm not 100% sure about that, but that's the only explanation I have. > It crashes here: > > QPrinter printer; > if (QPrintDialog(&printer).exec() == QDialog::Accepted) > > and the same command works flawlessly if I write a simple hello world > application. Also, if I skip the QPrintDialog and just print (that is: > if I modify and recompile source) it starts working. It might or might > not be connected with forking, but I have no clue where to look. > Here's what gets printed into gnuplot screen: > > gnuplot_qt[69041]<Error>: kCGErrorIllegalArgument: _CGSFindSharedWindow: WID -1 > gnuplot_qt[69041]<Error>: kCGErrorFailure: Set a breakpoint @ > CGErrorBreakpoint() to catch errors as they are logged. > gnuplot_qt[69041]<Error>: kCGErrorIllegalArgument: > CGSSetWindowShadowAndRimParametersWithStretch: Invalid window > 0xffffffff > > But printing is not critical. The _CGSFindSharedWindow WID -1 sure would make one think it might be a fork() issue. Fork is supposed to replicate the current process stack/state, but perhaps that doesn't apply to what is happening in the Qt library. Maybe another Qt initialization needs to be done for the forked process? Just guessing. Dan |
|
From: Mojca M. <moj...@gm...> - 2012-08-22 15:00:43
|
On Wed, Aug 22, 2012 at 4:10 PM, Daniel J Sebald wrote: > On 08/22/2012 04:05 AM, Mojca Miklavec wrote: >> >> gnuplot_qt[69041]<Error>: kCGErrorIllegalArgument: _CGSFindSharedWindow: >> WID -1 >> gnuplot_qt[69041]<Error>: kCGErrorFailure: Set a breakpoint @ >> CGErrorBreakpoint() to catch errors as they are logged. >> gnuplot_qt[69041]<Error>: kCGErrorIllegalArgument: >> CGSSetWindowShadowAndRimParametersWithStretch: Invalid window >> 0xffffffff >> >> But printing is not critical. > > The _CGSFindSharedWindow WID -1 sure would make one think it might be a > fork() issue. Fork is supposed to replicate the current process > stack/state, but perhaps that doesn't apply to what is happening in the Qt > library. Maybe another Qt initialization needs to be done for the forked > process? Just guessing. Ideally one could probably avoid forking altogether. (I believe that Qt is powerful enough to handle key events properly, but it's pointless to speculate without trying to write the code.) So until someone knowledgeable steps up (like for broken wxt on mac), this remains a mystery ;) Mojca |
|
From: Petr M. <mi...@ph...> - 2012-08-22 10:03:45
|
> What is the status of the Qt terminal? It easily builds and works on
> linux systems.
Not here, I still see the error I reported in January:
***************************************
During make, I see:
/usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/bin/rcc: Command
not found
make[3]: *** [qrc_QtGnuplotResource.cpp] Error 127
and similarly for lrelease.
Directory
/usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1
does not exist; rcc and lrelease are directly in /usr/bin/.
Is this a bug in pkg-config? Here is what I get with pkg-config:
$ pkg-config --variable=rcc_location QtCore
/usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/bin/rcc
$ pkg-config --variable=uic_location QtCore
/usr/bin/uic
Among others, the following libraries are installed:
libqt4-devel-4.7.1-154.1
qt3-devel-3.3.8b-87.11
qt3-3.3.8b-87.11
It's on OpenSUSE 11.1 with KDE3.
***************************************
I think the problem is in configure.in which contains this check:
RCC=`$PKG_CONFIG --variable=rcc_location QtCore`
if test x"$RCC" = x ; then
if test x"$QT4LOC" != x ; then
RCC=$QT4LOC/bin/rcc
else
RCC=rcc
fi
fi
I think it should be replaced by
if "$QT4LOC/bin/rcc exists"
then RCC=$QT4LOC/bin/rcc
else RCC=rcc
and similarly for lrelease.
Petr
|
|
From: Daniel J S. <dan...@ie...> - 2012-08-22 14:45:53
|
On 08/22/2012 05:03 AM, Petr Mikulik wrote:
>> What is the status of the Qt terminal? It easily builds and works on
>> linux systems.
>
> Not here, I still see the error I reported in January:
>
> ***************************************
>
> During make, I see:
>
> /usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/bin/rcc: Command
> not found
> make[3]: *** [qrc_QtGnuplotResource.cpp] Error 127
>
> and similarly for lrelease.
>
> Directory
> /usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1
> does not exist; rcc and lrelease are directly in /usr/bin/.
>
> Is this a bug in pkg-config? Here is what I get with pkg-config:
>
> $ pkg-config --variable=rcc_location QtCore
> /usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/bin/rcc
>
> $ pkg-config --variable=uic_location QtCore
> /usr/bin/uic
>
>
> Among others, the following libraries are installed:
> libqt4-devel-4.7.1-154.1
> qt3-devel-3.3.8b-87.11
> qt3-3.3.8b-87.11
>
> It's on OpenSUSE 11.1 with KDE3.
>
> ***************************************
>
> I think the problem is in configure.in which contains this check:
>
> RCC=`$PKG_CONFIG --variable=rcc_location QtCore`
> if test x"$RCC" = x ; then
> if test x"$QT4LOC" != x ; then
> RCC=$QT4LOC/bin/rcc
> else
> RCC=rcc
> fi
> fi
>
> I think it should be replaced by
> if "$QT4LOC/bin/rcc exists"
> then RCC=$QT4LOC/bin/rcc
> else RCC=rcc
>
> and similarly for lrelease.
If the
if test x"$QT4LOC" != x
is removed and QT4LOC happens to not be defined, then the line
then RCC=$QT4LOC/bin/rcc
will fail during configure. So you might have to place the proposed
test one level deeper inside the check for $QT4LOC.
How exactly you get
/usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/
for QT4LOC I'm not sure. I'm guessing that is where KDE has put the
latest Qt 4/5? Because
> libqt4-devel-4.7.1-154.1
> qt3-devel-3.3.8b-87.11
> qt3-3.3.8b-87.11
suggests to me you don't have Qt4 on your system. Just the code for
building the Qt4 library.
So, what you are proposing is that if the rcc for Qt4 does not exist at
the expected location, configure just falls back on "rcc". I suppose
that is the best that can be hoped for.
What happens when you type "rcc" at a command line? I'm using FC14 and get
[root@moorglade gnuplot]# rcc -version
Qt Resource Compiler version 4.7.4
so I know that my tools/resources are of the Qt4 variety. I'm wondering
if yours might not be.
Dan
>
> Petr
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
--
Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com
|
|
From: Mojca M. <moj...@gm...> - 2012-08-22 11:21:19
|
On Wed, Aug 22, 2012 at 12:03 PM, Petr Mikulik wrote:
>> What is the status of the Qt terminal? It easily builds and works on
>> linux systems.
>
> Not here, I still see the error I reported in January:
>
> ***************************************
>
> During make, I see:
>
> /usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/bin/rcc: Command
> not found
> make[3]: *** [qrc_QtGnuplotResource.cpp] Error 127
>
> and similarly for lrelease.
>
> Directory
> /usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1
> does not exist; rcc and lrelease are directly in /usr/bin/.
>
> Is this a bug in pkg-config? Here is what I get with pkg-config:
>
> $ pkg-config --variable=rcc_location QtCore
> /usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/bin/rcc
I get (properly)
/opt/local/bin/rcc
on Mac. The file
/opt/local/lib/pkgconfig/QtCore.pc
defines
prefix=/opt/local
rcc_location=${prefix}/bin/rcc
This means that there's a bug in your linux distribution, specifically
in the qt package. My guess is that QtCore.pc uses wrong settings. Can
you please send the contents of that file?
> $ pkg-config --variable=uic_location QtCore
> /usr/bin/uic
>
>
> Among others, the following libraries are installed:
> libqt4-devel-4.7.1-154.1
I guess this is the one being used. Try to locate QtCore.pc and send
the contents.
> qt3-devel-3.3.8b-87.11
> qt3-3.3.8b-87.11
>
> It's on OpenSUSE 11.1 with KDE3.
>
> ***************************************
>
> I think the problem is in configure.in which contains this check:
>
> RCC=`$PKG_CONFIG --variable=rcc_location QtCore`
> if test x"$RCC" = x ; then
> if test x"$QT4LOC" != x ; then
> RCC=$QT4LOC/bin/rcc
> else
> RCC=rcc
> fi
> fi
>
> I think it should be replaced by
> if "$QT4LOC/bin/rcc exists"
> then RCC=$QT4LOC/bin/rcc
> else RCC=rcc
If your Qt configuration (QtCore.pc) is problematic, you could easily
end up with
QT4LOC=`$PKG_CONFIG --variable=exec_prefix QtCore`
conveniently setting
QT4LOC=/usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1
for you (note that if you set QT4LOC yourself, it would be overwritten
in current implementation) and you would just as well end up with the
same wrong path to rcc. The patch that you proposed might solve the
problem for "broken installation in a certain way", but not for a
"broken installation in a different way".
There is definitely room for improvement for finding moc/rcc/lrelease.
If nothing else it seems as if there is no way to specify something
like
RCC=/usr/bin/rcc-4.8 ./configure --enable-qt
like it's possible to do for EMACS or PDFLATEX etc.
My suggestion would be to debug the problem with Qt4 on your
distribution first. Then patches can still be applied to Gnuplot's
./configure.in then.
But I definitely don't agree with this code:
> if "$QT4LOC/bin/rcc exists"
> then RCC=$QT4LOC/bin/rcc
> else RCC=rcc
Imagine a properly configured QtCore.pc listing:
prefix=/usr
exec_prefix=${prefix}
rcc_location=${prefix}/bin/rcc-4.8
In this case your proposal wouldn't work properly, while current
implementation would be ok.
Mojca
|
|
From: Petr M. <mi...@ph...> - 2012-08-22 12:19:51
|
> > $ pkg-config --variable=rcc_location QtCore
> > /usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/bin/rcc
>
> I get (properly)
> /opt/local/bin/rcc
> on Mac. The file
> /opt/local/lib/pkgconfig/QtCore.pc
> defines
> prefix=/opt/local
> rcc_location=${prefix}/bin/rcc
>
> This means that there's a bug in your linux distribution, specifically
> in the qt package. My guess is that QtCore.pc uses wrong settings. Can
> you please send the contents of that file?
less /usr/lib/pkgconfig/QtCore.pc
prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include/QtCore
qt_config=lex yacc warn_on uic resources qt warn_on release incremental
link_prl def_files_disabled exceptions no_mocdepend release stl
qt_no_framewo
rk system-sqlite release shared dll largefile stl mmx 3dnow sse sse2 sse3
ssse3 sse4_1 sse4_2 dylib create_prl link_prl depend_includepath QTDIR_buil
d nostrip qt_install_headers qt warn_on depend_includepath qmake_cache
target_qt hide_symbols bsymbolic_functions create_libtool create_pc
explicitli
b moc thread shared dll
moc_location=/usr/bin/moc
uic_location=/usr/bin/uic
rcc_location=${prefix}/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/bin/rcc
lupdate_location=${prefix}/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/bin/lupdate
lrelease_location=${prefix}/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/bin/lrelease
Name: Qtcore
Description: Qtcore Library
Version: 4.7.1
Libs: -L${libdir} -lQtCore
Libs.private: -L/usr/lib -L/usr/lib -lpthread -lz -lm -ldl -pthread
-lgthread-2.0 -lrt -lglib-2.0
Cflags: -DQT_SHARED -I/usr/include -I${includedir}
It seems that the rcc&lrelease location points to the temporary rpmbuild
location instead of the installation one. That's probably a bug indeed, but
I think gnuplot can easily deal with it:
> But I definitely don't agree with this code:
>
> > if "$QT4LOC/bin/rcc exists"
> > then RCC=$QT4LOC/bin/rcc
> > else RCC=rcc
>
> Imagine a properly configured QtCore.pc listing:
> prefix=/usr
> exec_prefix=${prefix}
> rcc_location=${prefix}/bin/rcc-4.8
> In this case your proposal wouldn't work properly, while current
> implementation would be ok.
I see, so I propose the following patch (3 lines added):
RCC=`$PKG_CONFIG --variable=rcc_location QtCore`
if test x"$RCC" = x ; then
if test x"$QT4LOC" != x ; then
RCC=$QT4LOC/bin/rcc
else
RCC=rcc
fi
fi
if ! test -f $RCC ; then
RCC=rcc
fi
---
Petr
|
|
From: Daniel J S. <dan...@ie...> - 2012-08-22 14:53:17
|
On 08/22/2012 07:19 AM, Petr Mikulik wrote:
>>> $ pkg-config --variable=rcc_location QtCore
>>> /usr/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/bin/rcc
>>
>> I get (properly)
>> /opt/local/bin/rcc
>> on Mac. The file
>> /opt/local/lib/pkgconfig/QtCore.pc
>> defines
>> prefix=/opt/local
>> rcc_location=${prefix}/bin/rcc
>>
>> This means that there's a bug in your linux distribution, specifically
>> in the qt package. My guess is that QtCore.pc uses wrong settings. Can
>> you please send the contents of that file?
>
>
> less /usr/lib/pkgconfig/QtCore.pc
[snip]
> moc_location=/usr/bin/moc
> uic_location=/usr/bin/uic
> rcc_location=${prefix}/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/bin/rcc
That explains where the strange definition for QT4LOC is coming from.
Why they are defining it that way, I'm not sure. Check your package
manager for any other packages related to Qt4 and look inside to see if
there is a version of "rcc" inside those packages. Perhaps a dependency
was overlooked and it is just a matter of bad maintenance. Or perhaps
there is an update to some package.
Dan
|
|
From: Mojca M. <moj...@gm...> - 2012-08-22 14:59:05
|
On Wed, Aug 22, 2012 at 4:53 PM, Daniel J Sebald wrote:
> On 08/22/2012 07:19 AM, Petr Mikulik wrote:
>>
>> rcc_location=${prefix}/src/packages/BUILD/qt-everywhere-opensource-src-4.7.1/bin/rcc
>
> That explains where the strange definition for QT4LOC is coming from. Why
> they are defining it that way, I'm not sure. Check your package manager for
> any other packages related to Qt4 and look inside to see if there is a
> version of "rcc" inside those packages. Perhaps a dependency was overlooked
> and it is just a matter of bad maintenance.
Bad maintenance. Bug closed as "NO RESPONSE" here:
https://bugzilla.novell.com/show_bug.cgi?id=715882
One should reopen it or file a new one.
Under MacPorts there were actually a lot of places that needed a fix
before or after ./configure && make to make the qt4 installation work
properly.
Mojca
|
|
From: Ethan A M. <sf...@us...> - 2012-08-22 17:19:29
|
On Wednesday, August 22, 2012 07:10:44 am Daniel J Sebald wrote: > If the Qt terminal is included with the next release and the user > doesn't have Qt operational on his or her system, what will happen? > That's all I meant. So far the inclusion of the qt terminal is optional and must be requested specifically via ./configure --enable-qt If you enable it but do not have the required dependencies installed then you get a configuration error message and gnuplot is built without qt even though you requested it. In the 4.6 release notes it is recommended to distribution packagers that they pick one of X11/wxt/qt for the package configuration rather than cramming all of them into a single build. This is especially true since the wxt and qt terminals cannot be used together in a single session anyhow. I have not tried to track the extent to which individual distros have followed this suggestion. Mojca Miklavec <moj...@gm...> wrote: > [ OpenSUSE 11.1 pkg-config error ] > Bad maintenance. Bug closed as "NO RESPONSE" here: > https://bugzilla.novell.com/show_bug.cgi?id=715882 > One should reopen it or file a new one. I don't think we should try too hard to retroactively work around distro packaging errors. It was never our error, OpenSUSE has fixed it in a later release, and the work-around is obvious from both the gnuplot and the SUSE bug trackers. Let's just disregard this and move on. Ethan |
|
From: Daniel J S. <dan...@ie...> - 2012-08-22 17:56:23
|
On 08/22/2012 12:00 PM, Ethan A Merritt wrote: > On Wednesday, August 22, 2012 07:10:44 am Daniel J Sebald wrote: > >> If the Qt terminal is included with the next release and the user >> doesn't have Qt operational on his or her system, what will happen? >> That's all I meant. > > So far the inclusion of the qt terminal is optional and must be requested > specifically via > ./configure --enable-qt > > If you enable it but do not have the required dependencies installed then > you get a configuration error message and gnuplot is built without qt even > though you requested it. OK. > In the 4.6 release notes it is recommended to distribution packagers that > they pick one of X11/wxt/qt for the package configuration rather than > cramming all of them into a single build. This is especially true since > the wxt and qt terminals cannot be used together in a single session > anyhow. I have not tried to track the extent to which individual distros > have followed this suggestion. I don't know if leaving out the X11 terminal is a good idea. At least one of the apps I know of will choose "x11" if the user doesn't set an environment variable specifying an alternative gnuplot terminal. So, if the distro creators leave out x11 that will cause problems in at least this case. To address this, the app will have to adjust accordingly but that means the distro creator will also have to get the latest for that app. Is there some way for an external app to get back to the default terminal when gnuplot is launched? That would solve the issue so that apps to have to specify a window based upon what system they run on. Is there some way for an external app to query what the available terminals are? ... OK just tried a few things. I see the way to get back to the default terminal is with "set term pop". That's provided a "set term push" hasn't been done. It's not exactly the same as going back to the default. Why does "unset term" behave the way it does? It basically is the same as "set term", i.e., displays a list of available terminals. Why would a list be displayed for an operation that wants to unset something? For example, one wouldn't write "unset term eps". > Mojca Miklavec<moj...@gm...> wrote: >> [ OpenSUSE 11.1 pkg-config error ] >> Bad maintenance. Bug closed as "NO RESPONSE" here: >> https://bugzilla.novell.com/show_bug.cgi?id=715882 >> One should reopen it or file a new one. > > I don't think we should try too hard to retroactively work around > distro packaging errors. It was never our error, OpenSUSE has fixed > it in a later release, and the work-around is obvious from both the > gnuplot and the SUSE bug trackers. Let's just disregard this and > move on. Yeah, that one isn't an issue, just bad luck. As far as my operation, Qt looks nice aside from the print problem Mojca reports and a small bug in the coordinate computations for the key box that I created a bug-report for. Then there is Windows Qt; I'll see if I can find someone interested in testing that. Dan |
|
From: Ethan A M. <sf...@us...> - 2012-08-22 18:22:16
|
On Wednesday, August 22, 2012 10:56:11 am Daniel J Sebald wrote: > I don't know if leaving out the X11 terminal is a good idea. At least > one of the apps I know of will choose "x11" if the user doesn't set an > environment variable specifying an alternative gnuplot terminal. So, if > the distro creators leave out x11 that will cause problems in at least > this case. > > To address this, the app will have to adjust accordingly but that means > the distro creator will also have to get the latest for that app. > > Is there some way for an external app to get back to the default > terminal when gnuplot is launched? That would solve the issue so that > apps to have to specify a window based upon what system they run on. Is > there some way for an external app to query what the available terminals > are? The variable GNUTERM is set to the starting terminal type on entry. So you can execute "set term GNUTERM" when you want to go back to it. > ... OK just tried a few things. I see the way to get back to the > default terminal is with "set term pop". That's provided a "set term > push" hasn't been done. It's not exactly the same as going back to the > default. I agree. IMHO "set term push/pop" is misleading because you would expect it to maintain a stack but it doesn't. > Why does "unset term" behave the way it does? It basically is > the same as "set term", i.e., displays a list of available terminals. > Why would a list be displayed for an operation that wants to unset > something? For example, one wouldn't write "unset term eps". For that matter, "set term" is also a strange way to get a list of options. "help term" or "help set term" would be more natural. Anyhow, I think in the current versions "set term GNUTERM" is the best way to get back to the starting state. Perhaps "unset term" should do the same thing, but that would be a change from previous versions. Ethan |
|
From: Daniel J S. <dan...@ie...> - 2012-08-22 18:37:48
|
On 08/22/2012 01:20 PM, Ethan A Merritt wrote: > On Wednesday, August 22, 2012 10:56:11 am Daniel J Sebald wrote: >> I don't know if leaving out the X11 terminal is a good idea. At least >> one of the apps I know of will choose "x11" if the user doesn't set an >> environment variable specifying an alternative gnuplot terminal. So, if >> the distro creators leave out x11 that will cause problems in at least >> this case. >> >> To address this, the app will have to adjust accordingly but that means >> the distro creator will also have to get the latest for that app. >> >> Is there some way for an external app to get back to the default >> terminal when gnuplot is launched? That would solve the issue so that >> apps to have to specify a window based upon what system they run on. Is >> there some way for an external app to query what the available terminals >> are? > > The variable GNUTERM is set to the starting terminal type on entry. > So you can execute "set term GNUTERM" when you want to go back to it. Oh, OK. That's a good bit of info, thanks. >> ... OK just tried a few things. I see the way to get back to the >> default terminal is with "set term pop". That's provided a "set term >> push" hasn't been done. It's not exactly the same as going back to the >> default. > > I agree. IMHO "set term push/pop" is misleading because you would expect > it to maintain a stack but it doesn't. Right. The stack is one deep. That's not real flexible. >> Why does "unset term" behave the way it does? It basically is >> the same as "set term", i.e., displays a list of available terminals. >> Why would a list be displayed for an operation that wants to unset >> something? For example, one wouldn't write "unset term eps". > > For that matter, "set term" is also a strange way to get a list of options. > "help term" or "help set term" would be more natural. Agreed. > Anyhow, I think in the current versions "set term GNUTERM" is the best way > to get back to the starting state. Perhaps "unset term" should do the same > thing, but that would be a change from previous versions. The description for "help unset" does begin as follows: Options set using the `set` command may be returned to their default state by the corresponding `unset` command. At least there currently is a method to get back to the default. Dan |
|
From: Daniel J S. <dan...@ie...> - 2012-08-22 18:28:16
|
On 08/22/2012 12:56 PM, Daniel J Sebald wrote: > I don't know if leaving out the X11 terminal is a good idea. At least > one of the apps I know of will choose "x11" if the user doesn't set an > environment variable specifying an alternative gnuplot terminal. So, if > the distro creators leave out x11 that will cause problems in at least > this case. I should say that, as well, an app may want to have both x11 and qt, for example. A reasonable scenario is: run from the command line, x11, and run from a UI, qt. I've done some compilations here to check sizes: gnuplot with x11 and qt: 3462231 gnuplot with x11, no qt: 3067584 gnuplot with qt, no x11: (I don't see a way to disable x11 terminal) So, qt adds 13%. That is a fairly big addition if qt isn't used. For the qt user though it isn't a concern because of the added support. Dan |
|
From: Ethan A M. <sf...@us...> - 2012-08-22 18:41:17
|
On Wednesday, August 22, 2012 11:28:09 am Daniel J Sebald wrote: > On 08/22/2012 12:56 PM, Daniel J Sebald wrote: > > > I don't know if leaving out the X11 terminal is a good idea. At least > > one of the apps I know of will choose "x11" if the user doesn't set an > > environment variable specifying an alternative gnuplot terminal. So, if > > the distro creators leave out x11 that will cause problems in at least > > this case. > > I should say that, as well, an app may want to have both x11 and qt, for > example. A reasonable scenario is: run from the command line, x11, and > run from a UI, qt. > > I've done some compilations here to check sizes: > > gnuplot with x11 and qt: 3462231 > gnuplot with x11, no qt: 3067584 > > So, qt adds 13%. That is a fairly big addition if qt isn't used. For > the qt user though it isn't a concern because of the added support. If you care about total size you should include the respective outboard drivers: text data bss dec hex filename 1385735 72836 57408 1515979 1721cb gnuplot # includes x11 + wxt + qt 91517 4788 12704 109009 1a9d1 gnuplot_x11 141992 2120 744 144856 235d8 gnuplot_qt > gnuplot with qt, no x11: (I don't see a way to disable x11 terminal) ./configure --without-x |
|
From: Daniel J S. <dan...@ie...> - 2012-08-22 19:09:09
|
On 08/22/2012 01:38 PM, Ethan A Merritt wrote: > On Wednesday, August 22, 2012 11:28:09 am Daniel J Sebald wrote: >> On 08/22/2012 12:56 PM, Daniel J Sebald wrote: >> >>> I don't know if leaving out the X11 terminal is a good idea. At least >>> one of the apps I know of will choose "x11" if the user doesn't set an >>> environment variable specifying an alternative gnuplot terminal. So, if >>> the distro creators leave out x11 that will cause problems in at least >>> this case. >> >> I should say that, as well, an app may want to have both x11 and qt, for >> example. A reasonable scenario is: run from the command line, x11, and >> run from a UI, qt. >> >> I've done some compilations here to check sizes: >> >> gnuplot with x11 and qt: 3462231 >> gnuplot with x11, no qt: 3067584 >> >> So, qt adds 13%. That is a fairly big addition if qt isn't used. For >> the qt user though it isn't a concern because of the added support. > >> gnuplot with qt, no x11: (I don't see a way to disable x11 terminal) > > ./configure --without-x OK... gnuplot with x11 and qt: 3462231 gnuplot with x11, no qt: 3067584 gnuplot with qt, no x11: 3415747 So x11 adds 1.4% approximately. Not much. (If I recall, the term just packages the commands slightly and sends them on their way to gnuplot_x11.) > If you care about total size you should include the respective outboard drivers: > > text data bss dec hex filename > 1385735 72836 57408 1515979 1721cb gnuplot # includes x11 + wxt + qt > 91517 4788 12704 109009 1a9d1 gnuplot_x11 > 141992 2120 744 144856 235d8 gnuplot_qt I'm discounting that because if I build with qt and run gnuplot, gnuplot_x11 outboard driver doesn't appear. Actually, qt is a little nicer along those lines because gnuplot_qt doesn't appear in the process list until an actual plot is done even though the qt terminal is set. On the other hand, gnuplot_x11 appears without having yet done a plot. It would be nice to change that, but even as is I think including X11 in any case isn't a concern. Dan |
