On 2009-09-01 09:12+0200 Werner Smekal wrote: >> This is improbable (since color_info is read immediately >> before >> in the code with fgets above), but it would be good to have rock-solid >> confirmation that this improbability is not true. > > I only see text, spaces and linefeeds, so it should be ok (see attached png).
I agree that is completely clean of special characters (except for linefeeds in the right place). Thanks for that confirmation. >> One hypothesis that might explain (more or less) all three strange results >> is that dynamic loading of qt devices is linking in a Qt4 library that >> breaks sscanf (or fgets if color_info turns out to have some embedded >> non-printing characters) on your system in some way. I know that >> hypothesis >> is quite speculative/improbable so if somebody here can come up with some >> more probable hypothesis to explain these strange results, please speak up. > > Just to make it more strange. Nokia actually provides two packages of Qt - > cocoa and carbon, whil cocoa is the "new" API (use for Mac OS X 10.6). I > actually have two Macs here (both latest 10.5.8 and xcode) and on one I > installed the carbon binary package and on the other cocoa binary package > (see http://qt.nokia.com/downloads/mac-os-cpp). While the Qt carbon leads to > this strange cmap results, does Qt cocoa not print out this warnings - so the > file qt devices work regarding the color. But qtwidget is messed up again, > since the first plot appears (for multipage examples and after I click on the > plot, before only grey window), but the following plots are not shown only > the background color. I really have to say that Qt on Mac OS X is quite buggy > as it seems. I have to agree. Thanks for all these tests. >> Hazen and Jerry: would you do similar experimentation (running example 16 >> with a number of different Qt4 versions) to see if you can replicate the >> issue that Werner found? To switch from one Qt4 version to another, simply >> put the appropriate qmake on your path before a fresh build and cmake does >> the rest. > > I used the binary packages, where a switch is not that easy. I just don't > have the time to download the 450Mb source package and compile qt in > different versions, which I assume will really take a long time, if this > 450MB monster is uncompressed. I don't believe compilation will be necessary so using the SDK may be a lot more straightforward than you think. Just to give my own experience, on Linux I downloaded the Qt4 SDK (software development kit) from https://edit.qt.troll.no/downloads). I have forgotten where I got the subsequent instructions, but here are my notes of exactly what I did. chmod u+x qt-sdk-linux-x86_64-opensource-2009.02.bin ./qt-sdk-linux-x86_64-opensource-2009.02.bin i.e., I changed the permission to execute and then ran that downloaded installer binary application. That installer then gave you a GUI where you could choose the installation prefix. By default that was a non-system location (/home/software/qtsdk-2009.02 for me where "software" is the name of the user account where I did the install). After that, the installation was quite fast with lots of disk activity but no cpu activity consistent with just getting a binary installed from the downloaded SDK rather than actually compiling it. I suspect if you download the 442MB Qt4 SDK for Mac OS X (see https://edit.qt.troll.no/downloads) it will also result in a binary install to a non-system location. After that, if you put that binary installs version of qmake (/home/software/qtsdk-2009.02/qt/bin/qmake in my case) on your PATH, then a fresh build of PLplot will just use that version of Qt4 with no interference from your system version. To Werner, Hazen, and Jerry: There is no mention on the above trolltech site whether the downloaded SDK for Mac OS X is packaged with Carbon or Cocoa or neither, but since the Carbon and Cocoa system packages for Qt4 seem to be broken in various ways for Werner regardless of Qt4 version, you might want just avoid those and use the downloadable trolltech Qt4 SDK instead. I also have the same advice (use the trolltech Qt4 SDK) on both Linux and Windows platforms. On Linux, that SDK version was certainly the most reliable version of Qt4 for me. That makes a lot of sense since Trolltech is the world's expert on building Qt4, and, of course, the SDK is their recommended version of Qt4. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
