Menu
▾
▴
gnuplot-beta
|
From: Jérôme L. <jer...@al...> - 2009-02-02 06:16:26
|
Hi, I have written a Qt terminal for Gnuplot. My main motivation for doing this is that Qt is going to be released under the LGPL, and I far as I understood, this license is compatible with Gnuplot. The terminal is mostly inspired from the wxWidgets terminal (thanks Timothée for your hard work !). It is not yet optimized and there are still some glitches here and there, but it is mostly feature complete. If it is of interest for someone, I will be happy to propose a patch. Screenshots: http://lodewyck.free.fr/gp1.png http://lodewyck.free.fr/gp2.png http://lodewyck.free.fr/gp3.png Regards, Jérôme |
|
From: Petr M. <mi...@ph...> - 2009-08-26 09:15:53
|
I've updated the Qt library to 4.5 and thus I could try the new Qt terminal. It works well. I have few comments: - "Export to pdf" produces file with the plot on top of the paper sheet. I would like if the dialog can give options for: - Center the plot on the paper. - Export only the figure (i.e. no page, but cropped image), as "set term pdf" is doing. - Could the "Export to image" ask for the image size? E.g. 800x600 etc. - If antialias is off, then rotation by mouse of "set pm3d; splot x*x" has the same speed as x11 terminal. If antialias is on, then it rotates much slower. - The first two zoom icons should rather have arrows (<-) and (->) instead of (-) and (+). - I think the terminal could write its own set-up as wxt is doing, i.e. $HOME/.gnuplot-qt - I think the default font could be saved in that config file (having a button for font dialog in the setup dialog). - I would enjoy very much the "space" hotkey functionality as in other terminals. --- PM |
|
From: Christoph B. <us...@be...> - 2009-08-26 10:07:19
|
Petr Mikulik schrieb: > I've updated the Qt library to 4.5 and thus I could try the new Qt terminal. > It works well. I tried it, too. Looks good. Why does it require Qt library 4.5? In his initial announcement in february Jérôme said, that he developed it with version 4.4.3. I compiled it with this version on Debian stable. It compiled without warnings and I could not encounter any error up to now (I did only a few plots). If version 4.4.3 is sufficient, it would be nice to adjust the requirements to this version because Debian stable ships this version. Nice work, Jérôme! Christoph |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-08-27 03:19:35
|
On Wednesday 26 August 2009 02:15:38 Petr Mikulik wrote: > > - Could the "Export to image" ask for the image size? E.g. 800x600 etc. I think it just dumps the current bitmap, so won't it always be the same size as the current plot window? > - If antialias is off, then rotation by mouse of "set pm3d; splot x*x" has > the same speed as x11 terminal. If antialias is on, then it rotates much > slower. Now this is an excellent point. I bet that the interactive performance can be improved by disabling antialiasing while the mouse button is held down. As you rotate, the refresh will be fast. When you release the mouse button, it can return to the antialiasing mode if that was previously enabled. > - The first two zoom icons should rather have arrows (<-) and (->) > instead of (-) and (+). Hmm. I'm more used to seeing + and - these days. Whatever. It's configurable. Ethan |
|
From: <pl...@pi...> - 2009-08-27 10:07:23
|
Ethan Merritt wrote: > > - The first two zoom icons should rather have arrows (<-) and (->) > > instead of (-) and (+). >Hmm. I'm more used to seeing + and - these days. Whatever. It's configurable. > Ethan I would have thought arrows represent a history "previous", "next" rather than zoom level. If it's a zoom level +,- makes more sense. /Peter |
|
From: Petr M. <mi...@ph...> - 2009-08-27 14:02:42
|
> > - Could the "Export to image" ask for the image size? E.g. 800x600 etc. > > I think it just dumps the current bitmap, so won't it always be the same > size as the current plot window? That's what I wonder. If it is a bitmap, I propose an option for cropping the image (to remove possible white edges when pasted into a document). > > - If antialias is off, then rotation by mouse of "set pm3d; splot x*x" has > > the same speed as x11 terminal. If antialias is on, then it rotates much > > slower. > > Now this is an excellent point. > I bet that the interactive performance can be improved by disabling > antialiasing while the mouse button is held down. As you rotate, the > refresh will be fast. When you release the mouse button, it can return > to the antialiasing mode if that was previously enabled. That would be perfect. > > - The first two zoom icons should rather have arrows (<-) and (->) > > instead of (-) and (+). > > Hmm. I'm more used to seeing + and - these days. Whatever. It's configurable. > I would have thought arrows represent a history "previous", "next" > rather than zoom level. If it's a zoom level +,- makes more sense. These icons mean previous and next item of the history, so arrows would be better. --- PM |
|
From: Mojca M. <moj...@gm...> - 2012-01-08 16:45:14
|
(I'm renaming the thread from "[ gnuplot-Bugs-3468950 ] Qt, moc and
uic not found on Mac OS X" since I have made it so long and the
discussion has departed from moc/uic long time ago already.)
Dear Jérôme,
I would like to sincerely thank you for the patches you sent me. It
seems that the terminal finally works normally now.
2012/1/8 Jérôme Lodewyck wrote:
> Hi,
>
> what about this new patch ? (I'm not even sure it compiles, because it
> makes use of the cocoa API which I cannot test here)
I had to replace Cocoa/Cocoa.h with Carbon/Carbon.h. Import of Cocoa
doesn't work and I have no idea why (maybe because it is in Objective
C and some compiler flags bail?). I also have no idea how safe it is
to use Carbon, but apparently it worked this time.
Now there are still two windows popping up, but the first one gets
closed soon afterwards and the second one gets a gnuplot icon. So it
only remains a matter of neglegible cosmetic issue (it would be better
not to display the first window at all, but it is perfectly fine the
way it is working now). If it works fine on other operating systems,
this might be the solution to go for and if it ever turns out in
future that forking is not needed or that there is a better proposal
for communication with Qt, it can be changed at any later time.
Here is what gets written out when I start plotting:
> plot sin(x)
qt_init() ""
execGnuplotQt()
Remove the application icon fom the MAC OS X dock
qt_connectToServer "qtgnuplot42894" false
I can now also quit the Qt window which prints out:
> Quit application 42894 false
Qt terminal communication error: select() error 9 Bad file descriptor
gnuplot> plot cos(x)
qt_connectToServer "qtgnuplot42894" false
Could not connect gnuplot_qt "" . Staring a new one
execGnuplotQt()
qt_connectToServer "qtgnuplot42895" false
gnuplot>
My only remaining question that is pretty relevant for the user
experience: How can I convince the cursor to stay in terminal (text
mode) after entering some plotting command (and optionally still make
the plotting window pop in front of the screen)?
If I load "all.dem", I have to keep switching back to terminal to be
able to hit enter to continue after a pause. In X11 that is not
necessary (but I don't know how gnuplot with X11 works on Linux).
Other, less important issues:
- Trivial change: I would like to request renaming "gnuplot_qt" window
into something more descriptive and more like human-readable
application name. Even if that is just "Gnuplot" or maybe some mention
of Qt.
- Printing doesn't work, but I would not bother about that now; it
might be pretty complex to make it work; it might also be trivial, but
it is of much lower priority now.
- Plot size for qt is 640x480, for x11 it is 640x463, for wxt it is
640x402, but default font size in Qt is some 20-30 % smaller than in
x11, and x11 also contains coordinates in lower left corner;
consequently plot size in qt is 593x456, while for x11 it is 584x415
(didn't measure for wxt); bottomline: in Qt the window looks somewhat
too high. Would it be possible to make it smaller in y direction?
(Optimally the same size as wxt, but it doesn't have to be that
strict.)
- I would prefer slightly bigger default font size, but that is just
me. On my screen numbers in Qt terminal are 7 pixels high and on 800
pixels/177 mm that makes each number 1.55 mm. (In my editor I use 11
pixels.) I don't know what others think of that since it highly
depends on monitor resolution and operating system and one may always
argue that it is configurable. It seems that font size is declared to
be 9pt (at least I get the same result if I try "set term qt font
',9'"), but it is 7 pixels high. Just to make it clear: it *is*
readable, it is extremely well hinted (it's not antialiased), but it
is a tiny bit too small. My favourite size would be 12 (which would
make numbers 9 pixels high). I don't know which font is being used by
default though.
- I'm able to set arbitrary background color and it is remembered.
However I cannot change plot size, font size somewhere in settings and
ask gnuplot/qt to remember that. That would be much more useful for me
than background color. (Yes, I know that I can always use "set term qt
<whatever> to do that, but that's not the point.")
- I would expect the files (see list on the bottom***) to end up under
src/qtterminal or some under src/qtterminal/trans and not under src,
but that is just cosmetics. That way it is also easier to list them in
.cvsignore (I don't use cvs and I don't know any tool to translate
.cvsignore into .gitignore automatically, so that doesn't affect me
directly).
- Feature request (not sure about it): I really like menu-based
commands in windows. So even newbies are able to figure out some
commands without having to read help. Do others think that this would
make sense in Qt terminal?
- Feature request: I would like to have zoom in & left/right sliding
using mouse gestures, but this is something that I need to investigate
myself based on Qt tutorials. In contrast to wxWidgets, Qt has native
support for them. This means that gnuplot should not only listen to
scrolling wheel, but also to other more advanced events.
- Bug report: clipping part of plot with mouse in backwards direction
(starting at some point and then moving up and/or left) is buggy. It
works (clips properly), but displays in a weird way and leaves some
weird traces. I can create a screenshot if others are unable to
reproduce it. Clipping into the fourth quadrant (from upper left to
lower right corner) works and displays as expected.
- Request: This is the same with all interactive terminals though: I
would like to see current terminal options listed somewhere. For
example:
> set term png
Terminal type set to 'png'
Could not find/open font when opening font "arial", using internal
non-scalable font
Options are 'nocrop medium size 640,480 '
> set term pdfcairo
Terminal type set to 'pdfcairo'
Options are ' transparent fontscale 0.5 size 5.00in, 3.00in '
but
> set term x11
Terminal type set to 'x11'
Options are ' nopersist'
> set term wxt
Terminal type set to 'wxt'
Options are '0'
> set term qt
Terminal type set to 'qt'
Options are '0'
I find the listed options very helpful to help me decide which options
are available and which ones are the default. (Now, if I want to
figure out current window size, I need to create a screenshot, exact
crop and ask for number of pixels.)
>> (I don't particularly like the fact that I now
>> have to install gnuplot before running it, but if that is what it
>> takes, so let it be.
>
> You don't have to install it. You can define the environment variable
> export GNUPLOT_DRIVER_DIR=./src/
> to point to the directory where the gnuplot_qt executable is.
Thank you for the information.
>
>> (Where should the image
>> from setWindowIcon(QIcon(":/images/gnuplot")); come from?)
>
> the image is in the src/qtterminal/images/ directory, and is included in the
> executable by qrc using the configuration file QtGnuplotResource.qrc
Oh, thank you. Now I understand how it works. I will also start a new
thread about the icon. On Mac OS X the icon size 32x32 is way too
small (see attachments on
https://sourceforge.net/tracker/?func=detail&aid=3469808&group_id=2055&atid=352055;
on Mac it is suggested to provide icons of size up to 512x512). I
would like to suggest creating an official vector icon. (I have one
gnuplot-generated proposal in PDF; manually generated SVG clone is
attached on the link above; another option would be creating a 3D
model with PovRay and I'm willing to help with that, but I would need
to know what you think of that.)
Mojca
*** files in src:
# src/QtGnuplotApplication.o
# src/QtGnuplotEvent.o
# src/QtGnuplotItems.o
# src/QtGnuplotScene.o
# src/QtGnuplotWidget.o
# src/QtGnuplotWindow.o
# src/moc_QtGnuplotApplication.cpp
# src/moc_QtGnuplotApplication.o
# src/moc_QtGnuplotEvent.cpp
# src/moc_QtGnuplotEvent.o
# src/moc_QtGnuplotScene.cpp
# src/moc_QtGnuplotScene.o
# src/moc_QtGnuplotWidget.cpp
# src/moc_QtGnuplotWidget.o
# src/moc_QtGnuplotWindow.cpp
# src/moc_QtGnuplotWindow.o
# src/qrc_QtGnuplotResource.cpp
# src/qrc_QtGnuplotResource.o
# src/qt_term.o
# src/qtgnuplot_fr.qm
# src/qtgnuplot_ja.qm
|
|
From: Ethan M. <merritt@u.washington.edu> - 2012-01-08 19:25:32
|
On Sunday, 08 January 2012, Mojca Miklavec wrote: > My only remaining question that is pretty relevant for the user > experience: How can I convince the cursor to stay in terminal (text > mode) after entering some plotting command (and optionally still make > the plotting window pop in front of the screen)? > If I load "all.dem", I have to keep switching back to terminal to be > able to hit enter to continue after a pause. In X11 that is not > necessary (but I don't know how gnuplot with X11 works on Linux). I do not have this problem with the qt terminal under linux, but to the best of my knowledge this is because of the setting "do not steal focus" in the window manager. I have no idea how you set the equivalent on OSX. The converse problem - sending the focus back to the terminal while you are trying to work with the plot window - is equally annoying but can be disabled by ./configure --disable-raise-console. > - Plot size for qt is 640x480, for x11 it is 640x463, for wxt it is > 640x402, but default font size in Qt is some 20-30 % smaller than in > x11, and x11 also contains coordinates in lower left corner; > consequently plot size in qt is 593x456, while for x11 it is 584x415 > (didn't measure for wxt); bottomline: in Qt the window looks somewhat > too high. Would it be possible to make it smaller in y direction? > (Optimally the same size as wxt, but it doesn't have to be that > strict.) Yeah, I also would prefer a different default aspect ratio. But there is plenty of precedent for 640x480 being the default size. That's what all of the bitmap terminals [use to] have. Maybe we could make it a user-settable preference in the tool widget. The wxt terminal maintains a preference file ~/.gnuplot-wxt so that the widget settings are persistent. I suppose the qt terminal could do the same. > - I'm able to set arbitrary background color and it is remembered. > However I cannot change plot size, font size somewhere in settings and > ask gnuplot/qt to remember that. That would be much more useful for me > than background color. (Yes, I know that I can always use "set term qt > <whatever> to do that, but that's not the point.") See above. > - Feature request (not sure about it): I really like menu-based > commands in windows. So even newbies are able to figure out some > commands without having to read help. Do others think that this would > make sense in Qt terminal? Ugh, no. > - Bug report: clipping part of plot with mouse in backwards direction > (starting at some point and then moving up and/or left) is buggy. It > works (clips properly), but displays in a weird way and leaves some > weird traces. Hmm. You are right. I don't remember this being a problem before. Could it have been broken by a recent change? > - I would expect the files (see list on the bottom***) to end up under > src/qtterminal or some under src/qtterminal/trans and not under src, > but that is just cosmetics. That way it is also easier to list them in > .cvsignore (I don't use cvs and I don't know any tool to translate > .cvsignore into .gitignore automatically, so that doesn't affect me > directly). I suggest to you that this is an example of why it is better not to configure + build on top of your primary source directory. I realize that different people have different work-flows, but messing up the contents of the directory tree you are using for source control strikes me as a poor choice. Perhaps you could use "make clean" or even "make distclean" before trying to commit any changes? Ethan |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-01-08 19:45:38
|
On Sunday, 08 January 2012, Ethan Merritt wrote: > > - Bug report: clipping part of plot with mouse in backwards direction > > (starting at some point and then moving up and/or left) is buggy. It > > works (clips properly), but displays in a weird way and leaves some > > weird traces. > > Hmm. You are right. > I don't remember this being a problem before. > Could it have been broken by a recent change? Mea culpa. Jérôme fixed this earlier, but I inadvertently reverted his fix when I did a too-broad commit of the source tree I was working from. I have just now restored the working version. Ethan |
|
From: Jérôme L. <lod...@us...> - 2012-01-08 21:24:00
Attachments:
qtgnuplot3.patch
|
Le Dimanche 8 Janvier 2012 17:45:08 vous avez écrit : > I had to replace Cocoa/Cocoa.h with Carbon/Carbon.h. Import of Cocoa > doesn't work and I have no idea why (maybe because it is in Objective > C and some compiler flags bail?). I also have no idea how safe it is > to use Carbon, but apparently it worked this time. Just for the fun, here is a version that should compile with Cocoa. Beware it breaks the build systems on non-OSX systems (I don't know how to conditionally add sources for a given OS in Makefile.am...). As far as I understand, the problem with Carbon is that it is somehow obsolete and apperently does not work on 64 bits systems. Jérôme |
|
From: Mojca M. <moj...@gm...> - 2012-03-31 15:24:38
Attachments:
gnuplot-qt-maconly.patch
gnuplot-qt-all.patch
|
On 2012-01-08, Jérôme Lodewyck wrote:
> Le Dimanche 8 Janvier 2012 17:45:08 vous avez écrit :
>> I had to replace Cocoa/Cocoa.h with Carbon/Carbon.h. Import of Cocoa
>> doesn't work and I have no idea why (maybe because it is in Objective
>> C and some compiler flags bail?). I also have no idea how safe it is
>> to use Carbon, but apparently it worked this time.
>
> Just for the fun, here is a version that should compile with Cocoa. Beware
> it
> breaks the build systems on non-OSX systems (I don't know how to
> conditionally
> add sources for a given OS in Makefile.am...). As far as I understand, the
> problem with Carbon is that it is somehow obsolete and apperently does not
> work on 64 bits systems.
I have prepared a patch against latest sources using your idea. I'm
attaching two files:
- gnuplot-qt-maconly.patch which attempts to solve this issue
- gnuplot-qt-all.patch which additionally solves three other issues
(trivial patches)
Now my latest observations:
1.) If I run ./prepare myself, the patch seems to work fine.
2.) I wanted to prepare a patch for MacPorts against 4.6.0 and since I
have a newer version of autotools, I wanted to include only the
relevant changes (leaving out all the parts that only have to do with
newer version of autotools). The funny part is that compiling the
result with CC=clang CXX=clang++ OBJC=clang worked fine, while the
compilation using the default compiler choked with with
c++ -DHAVE_CONFIG_H -I. -I.. -I../term -I../term
-DBINDIR=\"/path/to/gnuplot/inst/bin\"
-DX11_DRIVER_DIR=\"/path/to/gnuplot/inst/libexec/gnuplot/4.6\"
-DQT_DRIVER_DIR=\"/path/to/gnuplot/inst/libexec/gnuplot/4.6\"
-DGNUPLOT_SHARE_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6\"
-DGNUPLOT_PS_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6/PostScript\"
-DGNUPLOT_JS_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6/js\"
-DGNUPLOT_LUA_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6/lua\"
-DCONTACT=\"gnu...@li...\"
-DHELPFILE=\"/path/to/gnuplot/inst/share/gnuplot/4.6/gnuplot.gih\"
-DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\"
-DXAPPLRESDIR=\"/etc/X11/app-defaults/\"
-DQTGNUPLOT_DATA_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6/qt\"
-I/Library/Frameworks/QtCore.framework/Headers
-I/Library/Frameworks/QtGui.framework/Headers
-I/Library/Frameworks/QtNetwork.framework/Headers
-I/Library/Frameworks/QtSvg.framework/Headers -g -O2 -MT qt_term.o
-MD -MP -MF .deps/qt_term.Tpo -c -o qt_term.o `test -f
'qtterminal/qt_term.cpp' || echo './'`qtterminal/qt_term.cpp
In file included from qtterminal/qt_term.cpp:49:
In file included from ./plot.h:46:
./mouse.h:189:6: error: variable has incomplete type 'void'
void set_ruler __PROTO((TBOOLEAN on, int mx, int my));
^
./mouse.h:189:25: error: use of undeclared identifier '_Bool'; did you
mean 'QBool'?
void set_ruler __PROTO((TBOOLEAN on, int mx, int my));
^
./syscfg.h:368:18: note: expanded from macro 'TBOOLEAN'
#define TBOOLEAN bool
^
./syscfg.h:352:15: note: expanded from macro 'bool'
# define bool _Bool
^
./syscfg.h:189:25: note: expanded from macro '__PROTO'
# define __PROTO(proto) proto
^
In file included from qtterminal/qt_term.cpp:49:
In file included from ./plot.h:46:
./mouse.h:197:50: error: unknown type name '_Bool'; did you mean 'QBool'?
void bind_process __PROTO((char* lhs, char* rhs, TBOOLEAN allwindows));
^
./syscfg.h:368:18: note: expanded from macro 'TBOOLEAN'
#define TBOOLEAN bool
^
./syscfg.h:352:15: note: expanded from macro 'bool'
# define bool _Bool
^
./syscfg.h:189:25: note: expanded from macro '__PROTO'
# define __PROTO(proto) proto
^
/Library/Frameworks/QtCore.framework/Headers/qglobal.h:1976:7: note:
'QBool' declared here
class QBool
^
In file included from qtterminal/qt_term.cpp:49:
./plot.h:53:8: error: unknown type name '_Bool'; did you mean 'QBool'?
extern TBOOLEAN interactive;
^
./syscfg.h:368:18: note: expanded from macro 'TBOOLEAN'
#define TBOOLEAN bool
^
./syscfg.h:352:15: note: expanded from macro 'bool'
# define bool _Bool
^
/Library/Frameworks/QtCore.framework/Headers/qglobal.h:1976:7: note:
'QBool' declared here
class QBool
^
In file included from qtterminal/qt_term.cpp:49:
etc.
Even more funny is that:
> c++ --version
Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.3.0
> clang++ --version
Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.3.0
The gcc compiler fails with
g++ -DHAVE_CONFIG_H -I. -I.. -I../term -I../term
-DBINDIR=\"/path/to/gnuplot/inst/bin\"
-DX11_DRIVER_DIR=\"/path/to/gnuplot/inst/libexec/gnuplot/4.6\"
-DQT_DRIVER_DIR=\"/path/to/gnuplot/inst/libexec/gnuplot/4.6\"
-DGNUPLOT_SHARE_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6\"
-DGNUPLOT_PS_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6/PostScript\"
-DGNUPLOT_JS_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6/js\"
-DGNUPLOT_LUA_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6/lua\"
-DCONTACT=\"gnu...@li...\"
-DHELPFILE=\"/path/to/gnuplot/inst/share/gnuplot/4.6/gnuplot.gih\"
-DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\"
-DXAPPLRESDIR=\"/etc/X11/app-defaults/\"
-DQTGNUPLOT_DATA_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6/qt\"
-I/Library/Frameworks/QtCore.framework/Headers
-I/Library/Frameworks/QtGui.framework/Headers
-I/Library/Frameworks/QtNetwork.framework/Headers
-I/Library/Frameworks/QtSvg.framework/Headers -g -O2 -MT qt_term.o
-MD -MP -MF .deps/qt_term.Tpo -c -o qt_term.o `test -f
'qtterminal/qt_term.cpp' || echo './'`qtterminal/qt_term.cpp
In file included from ./plot.h:46,
from qtterminal/qt_term.cpp:49:
./mouse.h:189: error: variable or field ‘set_ruler’ declared void
./mouse.h:189: error: ‘_Bool’ was not declared in this scope
./mouse.h:189: error: expected primary-expression before ‘int’
./mouse.h:189: error: expected primary-expression before ‘int’
./mouse.h:197: error: ‘_Bool’ has not been declared
In file included from qtterminal/qt_term.cpp:49:
./plot.h:53: error: ‘_Bool’ does not name a type
./plot.h:54: error: ‘_Bool’ does not name a type
./plot.h:55: error: ‘_Bool’ does not name a type
In file included from ./color.h:72,
from ./term_api.h:46,
from qtterminal/qt_term.cpp:50:
./eval.h:86: error: ‘_Bool’ does not name a type
./eval.h:129: error: ‘_Bool’ does not name a type
./eval.h:148: error: ‘_Bool’ does not name a type
./eval.h:164: error: ‘_Bool’ has not been declared
In file included from qtterminal/qt_term.cpp:50:
./term_api.h:95: error: ‘_Bool’ does not name a type
./term_api.h:160: error: ‘_Bool’ does not name a type
./term_api.h:249: error: ‘_Bool’ has not been declared
./term_api.h:249: error: ‘_Bool’ has not been declared
./term_api.h:357: error: ‘_Bool’ does not name a type
./term_api.h:367: error: ‘_Bool’ does not name a type
./term_api.h:379: error: ‘_Bool’ does not name a type
./term_api.h:393: error: variable or field ‘term_check_multiplot_okay’
declared void
./term_api.h:393: error: ‘_Bool’ was not declared in this scope
./term_api.h:404: error: ‘_Bool’ has not been declared
./term_api.h:404: error: ‘_Bool’ has not been declared
./term_api.h:404: error: ‘_Bool’ has not been declared
./term_api.h:413: error: variable or field ‘ignore_enhanced’ declared void
./term_api.h:413: error: ‘_Bool’ was not declared in this scope
./term_api.h:416: error: ‘_Bool’ does not name a type
It is possible that I screwed something up during "backporting
configuration" (which is not a very well defined operation), that
there were some weird leftovers from somewhere, but it's also possible
that there are some problems in source code itself (maybe just a
missing header somewhere).
I would like to request somebody to:
- Review the patch and change parts if case that something needs to be changed.
- Confirm that the patch (either of the two) is harmless on platforms
other than Mac OS X.
- Test the patch on Mac OS X (if there is any mac volunteer on the
list at all) with different versions of Qt and different compilers.
- Send me (off-list) a zip of this patch applied + all the files that
get generated with ./prepare script, using the same version of
autotools that is usually used when creating gnuplot distribution. I
would like to figure out if there is a problem in my "backport" or in
some parts of the code. I have also found the following link with
google (claiming a bug in compiler):
http://stackoverflow.com/questions/7751411/xcode-4-error-unknown-type-name-bool-did-you-mean-bool
but the errors are not exactly the same.
I would still like to stress out that:
- the current code (with qt terminal) doesn't work out-of-the-box at all
- the attached patch kind-of-works; it always works when I run
./prepare myself and doesn't work if I do some weird juggling with
backporting and using the wrong compiler; it is still *a lot better*
than the current state though - at least it works most of the time
- there is most probably no influence in cases when qt is not built
and on non-mac platforms (both compilers that fail in cases above work
perfectly fine under exactly the same configuration, only with qt
disabled)
Mojca
|
|
From: Mojca M. <moj...@gm...> - 2012-01-08 22:03:25
|
2012/1/8 Jérôme Lodewyck wrote: > Le Dimanche 8 Janvier 2012 17:45:08 vous avez écrit : >> I had to replace Cocoa/Cocoa.h with Carbon/Carbon.h. Import of Cocoa >> doesn't work and I have no idea why (maybe because it is in Objective >> C and some compiler flags bail?). I also have no idea how safe it is >> to use Carbon, but apparently it worked this time. > > Just for the fun, here is a version that should compile with Cocoa. Thank you very much. It compiles and works fine (not that I understand what is the difference since AquaTerm is also using Objective C and there is no special compiler, maybe only some different flags). > Beware it > breaks the build systems on non-OSX systems (I don't know how to conditionally > add sources for a given OS in Makefile.am...). As far as I understand, the > problem with Carbon is that it is somehow obsolete and apperently does not > work on 64 bits systems. I'm not sure what is going one. I also believed that Carbon was 100% forbidden in 64-bit applications, but your previous code with Cocoa->Carbon worked and: > file /System/Library/Frameworks/Carbon.framework/Carbon /System/Library/Frameworks/Carbon.framework/Carbon: Mach-O universal binary with 2 architectures /System/Library/Frameworks/Carbon.framework/Carbon (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 /System/Library/Frameworks/Carbon.framework/Carbon (for architecture i386): Mach-O dynamically linked shared library i386 Maybe there is some core part of functionality in Carbon that still works, but even that might easily disappear at any given moment without notice. My bet is that next OS version won't ship Carbon at all. Mojca PS: what exactly is -DXAPPLRESDIR=\"/etc/X11/app-defaults/\"? That folder doesn't exist. |
|
From: Ethan M. <merritt@u.washington.edu> - 2012-01-08 23:40:08
|
On Sunday, 08 January 2012, Mojca Miklavec wrote: > PS: what exactly is -DXAPPLRESDIR=\"/etc/X11/app-defaults/\"? That > folder doesn't exist. Only relevant to the x11 terminal. It points to the folder where the system keeps default Xresource files. There doesn't seem to be any standard place even for linux/unix systems, so if you care about this (most people don't) you can configure it correctly for your system. The mechanism of configuring application behaviour via Xresources seems to have fallen out of favor, so most people can safely ignore all of this. Ethan |
|
From: Mojca M. <moj...@gm...> - 2012-01-08 22:29:56
|
On Sun, Jan 8, 2012 at 20:25, Ethan Merritt wrote: > On Sunday, 08 January 2012, Mojca Miklavec wrote: >> My only remaining question that is pretty relevant for the user >> experience: How can I convince the cursor to stay in terminal (text >> mode) after entering some plotting command (and optionally still make >> the plotting window pop in front of the screen)? > >> If I load "all.dem", I have to keep switching back to terminal to be >> able to hit enter to continue after a pause. In X11 that is not >> necessary (but I don't know how gnuplot with X11 works on Linux). > > I do not have this problem with the qt terminal under linux, but to > the best of my knowledge this is because of the setting "do not steal > focus" in the window manager. I have no idea how you set the > equivalent on OSX. The converse problem - sending the focus back to > the terminal while you are trying to work with the plot window - > is equally annoying but can be disabled by ./configure --disable-raise-console. I hope that somebody else will have more ideas. Now that Jérôme is playing with application settings like hiding windows, he might have seen something about switching focus as well. (But behaviour of focus of applications in Lion is somewhat buggy anyway. There are some aspects that I really hate. I'm unable to open a new window with apple+N in - say - web browser without the latest minimized window popping up as well.) > Yeah, I also would prefer a different default aspect ratio. > But there is plenty of precedent for 640x480 being the default size. What about other's opinions? > Maybe we could make it a user-settable preference in the tool widget. > The wxt terminal maintains a preference file ~/.gnuplot-wxt so that the > widget settings are persistent. I suppose the qt terminal could do the same. Where does Qt terminal store background color? >> - I'm able to set arbitrary background color and it is remembered. >> However I cannot change plot size, font size somewhere in settings and >> ask gnuplot/qt to remember that. That would be much more useful for me >> than background color. (Yes, I know that I can always use "set term qt >> <whatever> to do that, but that's not the point.") > > See above. 1.) I'm still curious to know where Qt terminal stores background color. 2.) It would be *really really really* nice if it was doable via GUI, in the same way as for background color. Yes, ~/.gnuplot<something> is always an option, but if some options like color can be configured in gui, I don't see a reason why others (plot size, font face & size) couldn't be. Mojca |
|
From: Jérôme L. <lod...@us...> - 2012-01-09 21:17:47
|
> > Maybe we could make it a user-settable preference in the tool widget. > > The wxt terminal maintains a preference file ~/.gnuplot-wxt so that the > > widget settings are persistent. I suppose the qt terminal could do the > > same. > Where does Qt terminal store background color? This is managed by the QSettings model in Qt. The location and format of the settings depends on the system and is chosen by the Qt library. It is hidden from the user and programmer. It is a config file under linux (~/.config/gnuplot/qtterminal.conf), in the registry on windows, and who knows where in OS X... Jérôme |
|
From: Mojca M. <moj...@gm...> - 2012-01-09 21:26:56
|
2012/1/9 Jérôme Lodewyck wrote: >> > Maybe we could make it a user-settable preference in the tool widget. >> > The wxt terminal maintains a preference file ~/.gnuplot-wxt so that the >> > widget settings are persistent. I suppose the qt terminal could do the >> > same. >> Where does Qt terminal store background color? > > This is managed by the QSettings model in Qt. The location and format of the > settings depends on the system and is chosen by the Qt library. It is hidden > from the user and programmer. It is a config file under linux > (~/.config/gnuplot/qtterminal.conf), in the registry on windows, and who knows > where in OS X... Thank you. Now I have found it. ~/Library/Preferences/gnuplot_qt.plist It should have had a different name (for the sake of cleanliness) though - all others that I have in that folder have something like net.sourceforge.aquaterm.plist, hu.mplayerhq.mplayerosx.extended.plist, org.tug.TeXworks.plist - also a Qt program, ... but that is not too important at the moment. I don't know how Qt decides about the filename. But I think that this would be the right place for storing default window size and font face/size. Mojca |
|
From: Ethan A M. <merritt@u.washington.edu> - 2009-02-02 06:26:37
|
On Sunday 01 February 2009, Jérôme Lodewyck wrote: > Hi, > > I have written a Qt terminal for Gnuplot. My main motivation for doing this > is that Qt is going to be released under the LGPL, and I far as I understood, > this license is compatible with Gnuplot. > The terminal is mostly inspired from the wxWidgets terminal (thanks Timothée > for your hard work !). It is not yet optimized and there are still some > glitches here and there, but it is mostly feature complete. > If it is of interest for someone, I will be happy to propose a patch. Sure, go ahead and post a patch. It is hard to tell much about how it works by looking only at screenshots. Please describe more precisely what libraries or environment thie new terminal would require. Does it use the KDE libraries, or just Qt? If one built gnuplot with only the driver, would it be run on, say, the OpenMoko mobile phone platform? What about non-linux Qt platforms? Ethan > > Screenshots: > > http://lodewyck.free.fr/gp1.png > http://lodewyck.free.fr/gp2.png > http://lodewyck.free.fr/gp3.png > > Regards, > > Jérôme > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Jérôme L. <jer...@al...> - 2009-02-02 20:28:43
|
Le lundi 2 février 2009, Ethan A Merritt a écrit : > On Sunday 01 February 2009, Jérôme Lodewyck wrote: > > Hi, > > > > I have written a Qt terminal for Gnuplot. My main motivation for doing > > this is that Qt is going to be released under the LGPL, and I far as I > > understood, this license is compatible with Gnuplot. > > The terminal is mostly inspired from the wxWidgets terminal (thanks > > Timothée for your hard work !). It is not yet optimized and there are > > still some glitches here and there, but it is mostly feature complete. > > If it is of interest for someone, I will be happy to propose a patch. > > Sure, go ahead and post a patch. > It is hard to tell much about how it works by looking only at screenshots. Ok, the patch is submitted > Please describe more precisely what libraries or environment thie new > terminal would require. > Does it use the KDE libraries, or just Qt? > If one built gnuplot with only the driver, would it be run on, say, > the OpenMoko mobile phone platform? > What about non-linux Qt platforms? It uses Qt 4 libraries. It was developed on Linux with Qt 4.4.3, but in my experience, Qt applications usually work out of the box on any platform supported by Qt (X11, windows, MacOS X, framebuffer linux, windows CE). Only one pat of the terminal makes use of non-Qt functions: the Qt main loop is implemented inside a pthread, which is a problem because 1/ It doesn't work on non-UNIX platforms, but from what I understood from the wx terminal, Windows support would only imply putting #ifdef's around the pthread functions 2/ Qt does not officially support running the main event loop inside a thread; however, I did not experience any problem with this (except that Qt functions should be used with care in the gnuplot thread) Jérôme > Ethan > > > Screenshots: > > > > http://lodewyck.free.fr/gp1.png > > http://lodewyck.free.fr/gp2.png > > http://lodewyck.free.fr/gp3.png > > > > Regards, > > > > Jérôme > > > > ------------------------------------------------------------------------- > >----- This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > http://p.sf.net/sfu/sf-spreadtheword > > _______________________________________________ > > gnuplot-beta mailing list > > gnu...@li... > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |
|
From: Philipp K. J. <ja...@ie...> - 2009-02-03 03:24:47
|
I think this is welcome! Thanks, Jerome! I have not looked at the code for this patch, but I have programmed Qt before, and I can say that it: - works really well - is incredibly well documented - has a very large set of useful widgets (although this does not do much for gnuplot right now). What would make this really, really cool is if it could truly leverage Qt's cross-platform capabilities, such that it would become easier to build and install gnuplot on Win and the Mac. By the same token, if it does NOT offer this cross-platform capability, then I need to understand better what this patch does that wxt is not doing already. Could you speak to that? Best, Ph. On Monday 02 February 2009 12:28:26 pm Jérôme Lodewyck wrote: > Le lundi 2 février 2009, Ethan A Merritt a écrit : > > On Sunday 01 February 2009, Jérôme Lodewyck wrote: > > > Hi, > > > > > > I have written a Qt terminal for Gnuplot. My main motivation for doing > > > this is that Qt is going to be released under the LGPL, and I far as I > > > understood, this license is compatible with Gnuplot. > > > The terminal is mostly inspired from the wxWidgets terminal (thanks > > > Timothée for your hard work !). It is not yet optimized and there are > > > still some glitches here and there, but it is mostly feature complete. > > > If it is of interest for someone, I will be happy to propose a patch. > > > > Sure, go ahead and post a patch. > > It is hard to tell much about how it works by looking only at > > screenshots. > > Ok, the patch is submitted > > > Please describe more precisely what libraries or environment thie new > > terminal would require. > > Does it use the KDE libraries, or just Qt? > > If one built gnuplot with only the driver, would it be run on, say, > > the OpenMoko mobile phone platform? > > What about non-linux Qt platforms? > > It uses Qt 4 libraries. It was developed on Linux with Qt 4.4.3, but in my > experience, Qt applications usually work out of the box on any platform > supported by Qt (X11, windows, MacOS X, framebuffer linux, windows CE). > Only one pat of the terminal makes use of non-Qt functions: the Qt main > loop is implemented inside a pthread, which is a problem because > 1/ It doesn't work on non-UNIX platforms, but from what I understood from > the wx terminal, Windows support would only imply putting #ifdef's around > the pthread functions > 2/ Qt does not officially support running the main event loop inside a > thread; however, I did not experience any problem with this (except that Qt > functions should be used with care in the gnuplot thread) > > Jérôme > > > Ethan > > > > > Screenshots: > > > > > > http://lodewyck.free.fr/gp1.png > > > http://lodewyck.free.fr/gp2.png > > > http://lodewyck.free.fr/gp3.png > > > > > > Regards, > > > > > > Jérôme > > > > > > ----------------------------------------------------------------------- > > >-- ----- This SF.net email is sponsored by: > > > SourcForge Community > > > SourceForge wants to tell your story. > > > http://p.sf.net/sfu/sf-spreadtheword > > > _______________________________________________ > > > gnuplot-beta mailing list > > > gnu...@li... > > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > > --------------------------------------------------------------------------- >--- This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |
|
From: Ethan A M. <merritt@u.washington.edu> - 2009-02-03 06:36:04
|
On Monday 02 February 2009, Philipp K. Janert wrote: > > I think this is welcome! Thanks, Jerome! > > I have not looked at the code for this patch, but > I have programmed Qt before, and I can say that it: > - works really well > - is incredibly well documented > - has a very large set of useful widgets (although > this does not do much for gnuplot right now). > > What would make this really, really cool is if it > could truly leverage Qt's cross-platform capabilities, > such that it would become easier to build and install > gnuplot on Win and the Mac. > > By the same token, if it does NOT offer this > cross-platform capability, then I need to understand > better what this patch does that wxt is not doing > already. Could you speak to that? I haven't tried this new driver yet, but if I understood the earlier description correctly, it probably suffers from exactly the same problem as wxt on Mac. The event loop is in a thread, and OSX does not like that. But we'll see. Ethan > > Best, > > Ph. > > > On Monday 02 February 2009 12:28:26 pm Jérôme Lodewyck wrote: > > Le lundi 2 février 2009, Ethan A Merritt a écrit : > > > On Sunday 01 February 2009, Jérôme Lodewyck wrote: > > > > Hi, > > > > > > > > I have written a Qt terminal for Gnuplot. My main motivation for doing > > > > this is that Qt is going to be released under the LGPL, and I far as I > > > > understood, this license is compatible with Gnuplot. > > > > The terminal is mostly inspired from the wxWidgets terminal (thanks > > > > Timothée for your hard work !). It is not yet optimized and there are > > > > still some glitches here and there, but it is mostly feature complete. > > > > If it is of interest for someone, I will be happy to propose a patch. > > > > > > Sure, go ahead and post a patch. > > > It is hard to tell much about how it works by looking only at > > > screenshots. > > > > Ok, the patch is submitted > > > > > Please describe more precisely what libraries or environment thie new > > > terminal would require. > > > Does it use the KDE libraries, or just Qt? > > > If one built gnuplot with only the driver, would it be run on, say, > > > the OpenMoko mobile phone platform? > > > What about non-linux Qt platforms? > > > > It uses Qt 4 libraries. It was developed on Linux with Qt 4.4.3, but in my > > experience, Qt applications usually work out of the box on any platform > > supported by Qt (X11, windows, MacOS X, framebuffer linux, windows CE). > > Only one pat of the terminal makes use of non-Qt functions: the Qt main > > loop is implemented inside a pthread, which is a problem because > > 1/ It doesn't work on non-UNIX platforms, but from what I understood from > > the wx terminal, Windows support would only imply putting #ifdef's around > > the pthread functions > > 2/ Qt does not officially support running the main event loop inside a > > thread; however, I did not experience any problem with this (except that Qt > > functions should be used with care in the gnuplot thread) > > > > Jérôme > > > > > Ethan > > > > > > > Screenshots: > > > > > > > > http://lodewyck.free.fr/gp1.png > > > > http://lodewyck.free.fr/gp2.png > > > > http://lodewyck.free.fr/gp3.png > > > > > > > > Regards, > > > > > > > > Jérôme > > > > > > > > ----------------------------------------------------------------------- > > > >-- ----- This SF.net email is sponsored by: > > > > SourcForge Community > > > > SourceForge wants to tell your story. > > > > http://p.sf.net/sfu/sf-spreadtheword > > > > _______________________________________________ > > > > gnuplot-beta mailing list > > > > gnu...@li... > > > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > > > > --------------------------------------------------------------------------- > >--- This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > http://p.sf.net/sfu/sf-spreadtheword > > _______________________________________________ > > gnuplot-beta mailing list > > gnu...@li... > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Jérôme L. <jer...@al...> - 2009-02-03 19:37:23
|
Le mardi 3 février 2009, Ethan A Merritt a écrit : > I haven't tried this new driver yet, but if I understood the earlier > description correctly, it probably suffers from exactly the same > problem as wxt on Mac. The event loop is in a thread, > and OSX does not like that. But we'll see. You are most probably right. However, this thread business was just a quick and dirty way to have the terminal working. Internally, all comunications between gnuplot core and the terminal itself are event based, so forking and using an IPC should be easy to implement. Jérôme |
|
From: Nigel N. <nn...@gm...> - 2009-02-03 20:54:24
|
On 2/3/09, Ethan A Merritt <merritt@u.washington.edu> wrote:
> I haven't tried this new driver yet, but if I understood the earlier
> description correctly, it probably suffers from exactly the same
> problem as wxt on Mac. The event loop is in a thread,
> and OSX does not like that. But we'll see.
Sorry for not getting around to submitting our wx alternative.
By building gnuplot as a library and exposing two functions,
int init_gnuplot(int bInteract);
int lib_do_line(const char *gp_cmd);
we can plug gnuplot into any application. If we just want ps or
pdf results, we pass lines to gnuplot by calling lib_do_line(...);
lib_do_line("set term post");
lib_do_line("set grid");
lib_do_line("plot 'results.dat' with lines");
A current project uses a wxPanel as a rendering canvas, and a
modified wxTextBox for a gui command line. Essentially HBB's
win.trm adjusted for wx. Simple, robust, and no threads.
Nigel
|
