By way of update:
On Tue, 2008-08-05 at 21:59 -0700, Alan W. Irwin wrote:
> If your install still fails with a misplaced plplot.mod file for a
> source tree and initially empty build tree, then I will have to think
> but the plplot.mod location logic works fine on my system for
> and the svn trunk version of PLplot so I cannot think of any reason
> why it would not work for you as well.
> In sum, I hope a pristine version of the svn trunk source code and an
> initially empty build tree solves your difficulties.
I can now confirm that a pristine svn trunk and my source-built cmake
2.6.1 on my Suse 10.2 system will now successfully complete a build and
install, though not all drivers work or will build. Here's a summary,
mostly in case someone else is interested. At the end you will also find
an update on our efforts to build a Qt "driver"
* itk/itcl enabled now behave themselves
* wxwidgets fail to build (with cmake 2.4patch6 they did compile):
&& /usr/bin/c++ -DHAVE_CONFIG_H -Dwxwidgets_EXPORTS -fPIC
-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -o
member function ‘virtual void wxPLDevDC::PutPixel(short int, short int,
/home/opt_home/plplot/plplot_svn_2008_08_06/drivers/wxwidgets_dc.cpp:218: error: ‘GetRValue’ was not declared in this scope
* HAVE_PTHREAD=ON will compile, but xwins still don't refresh if
overlaid, and tk window will then spew forth multiple free or other
error on exit
* gcw will draw ok, but seg faults the instant the cursor is moved
within the drawing surface
* (new) tkwin driver won't launch, complaining it can't find plframe
* svg files can't be opened by most editors (e.g.,inkscape) and viewers
(e.g., eye-of-gnome). In particular, it would be nice to find an editor
that could open them to touch up, etc. The Cairo svg's appear to be
better, but installing Cairo is an extra overhead.
* the ps and psc-generated files display fine - both within their own
bounding boxes and when given a papersize in, e.g., ghostview, but seem
to print a factor 5 too large to postscript printers (I've tried both hp
and Xerox ones). Running them through epstopdf or some other filter
works, but I wonder if someone else has noticed this and if this is a
bug in the driver.
Finally, as I mentioned to you, one of my developers is working on a Qt
plotting device; this seems to work and is a real bonus for us as the
application we supply to end users is written using Qt. As you noted, it
might also be of interest to the KDE community, or would run on any
system that has KDE. Qt is also available on windows, so it offers an
alternative to the wingcc device. In fact, the implementation isn't that
difficult, as it simply uses the plplot mem device and then displays the
result in a low-level Qt paint widget. It takes a bit more work to turn
it into an interactive device, but that seems in hand. And it can be
adorned with a menubar, like the tk or wxwidget drivers, to save/print,
Although our intention is to bundle this inside our Qt application, we
could try to construct it in a way that could be extracted for
standalone use if there is the interest.
Supplying the C++ class and api would be straightforward. It might take
a bit more effort/knowledge to turn this into a real plplot device with
suitable wrappers. And we couldn't really support languages/interfaces
other than C++.
Please advise whether there is any interest in the above, what would be
most useful, and if so who on the devel team would be in a position to
provide support (which probably translates into wrapping our C++ class
into something generic for plplot).
Professor Steven J Schwartz Phone: +44-(0)20-7594-7660
Space and Atmospheric Physics Fax: +44-(0)20-7594-7772
The Blackett Laboratory E-mail: s.schwartz@...
Imperial College London Office: Huxley 6M70
London SW7 2BW, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs