qwtplot3d-interest

Re: SIGSEGV from qwt3diodummy constructor

[Micha B. <kri...@us...>]

Monday, September 5, 2005, 17:59:57, Andreas Haumer wrote:

> a) why doesn't the crash on LabPlot happen on all systems
> b) why doesn't the crash happen on other qwtplot3d applications

At least regarding 2) - there is a labplot-like application out there
(qtiplot) with similar problems. I was never (for other reasons too) to
trace this back to the errors source.

> dependent. I think I might check the gcc mailing lists about
> this issue...

Not enough, dll's are similar beasts ...

> I'll inform the LabPlot maintainer about this development
> and I think he might use the new qwtplot3d version as soon
> as it is officially available.

This was my wish anyway, it might be from interest for Stefan.

> for the usual "configure; make; make install" commands to

It's not that usual. I'm personally no friend of autoconfig + friends,
but this is not the point. The library is platform independent. At least
up to the point Qt and OpenGL are. For example, almost all development
has been done on Windows. So, qmake is my choice.
Someone in the past offered packaging for qwt3d, but the issue came out
of sight to me during the time.
Amyway, if someone volunteers for the work, I could include the
configuration files in the official package and cvs.

Micha  
-- 

Re: SIGSEGV from qwt3diodummy constructor

[Andreas H. <an...@xs...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Micha Bieber schrieb:
|>What was the reason for the problem?
|
|
| The dummy object, any doubts ... :->
| My guess:
|
| We have a chain:
|
| app -> qwtplot3d.dll/so -> qt.dll/so
|
| Qt has to initialize some of its structures (QString ?). The
| construction for the qwt3d static object happens too early. Perhaps the
| qt shared library isn't full available/initialized at this point yet.
| Similar for destruction. I don't know and seeing the topic-relevant
| discussions in the net, I have to admit that I'm not even eager to know
| why ... .

Oh well... ;-)

But this all doesn't explain at least two things:

a) why doesn't the crash on LabPlot happen on all systems
b) why doesn't the crash happen on other qwtplot3d applications

I don't know what the c++ standard says about construction
of global static objects, but it seems to be system (compiler?)
dependent. I think I might check the gcc mailing lists about
this issue...

| Anyway, in order to circumvent the problem, I moved all needed static
| stuff inside functions (it's a common pattern). So whatever will be used
| is constructed first in place when the function is called for the first
| time. Because main runs then, order of initialization issues shouldn't
| be longer an issue.
|
This might be better practice anyway: global objects are ugly ;-)

Many thanks for your support!

I'll inform the LabPlot maintainer about this development
and I think he might use the new qwtplot3d version as soon
as it is officially available.

- - andreas

PS: do you plan to add the neccessary adminstrative files
for the usual "configure; make; make install" commands to
your library? That would make it much easier to create
installable packages of qwtplot3d and would perhaps
eliminate the need for integrating the sources directly
it into LabPlot.

- --
Andreas Haumer                     | mailto:an...@xs...
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDHGs/xJmyeGcXPhERAvF1AJ0VwMGMpZ/VKQ4S4DSMSng/rwN+2ACfYJJY
Niu5rbqvWZz9cXDaZgPj3Rg=
=WrtV
-----END PGP SIGNATURE-----

Re: SIGSEGV from qwt3diodummy constructor

[Micha B. <kri...@us...>]

> What was the reason for the problem?

The dummy object, any doubts ... :->
My guess:

We have a chain:

app -> qwtplot3d.dll/so -> qt.dll/so

Qt has to initialize some of its structures (QString ?). The
construction for the qwt3d static object happens too early. Perhaps the
qt shared library isn't full available/initialized at this point yet.
Similar for destruction. I don't know and seeing the topic-relevant
discussions in the net, I have to admit that I'm not even eager to know
why ... .
Anyway, in order to circumvent the problem, I moved all needed static
stuff inside functions (it's a common pattern). So whatever will be used
is constructed first in place when the function is called for the first
time. Because main runs then, order of initialization issues shouldn't
be longer an issue.

Micha  
-- 

Re: SIGSEGV from qwt3diodummy constructor

[Andreas H. <an...@xs...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Micha Bieber schrieb:
| Monday, September 5, 2005, 14:09:28, Andreas Haumer wrote:
|
| http://qwtplot3d.sourceforge.net/050904plot3d.tgz
|
|
|>Does not compile... :-(
|
|
| Ooops, erroneous uploaded. My mistake :-(
| I've replaced the archive by the correct sources now (unchanged URL)
|
Ok, I downloaded the new version and things are looking good now! :-)

Here's what I did:

a) Un-tared and compiled the new sources in /work/qwtplot3d.new

andreas@tolstoi:~ {1014} % ll /work/qwtplot3d.new/lib
insgesamt 387
drwxrwxr-x  2 andreas outlaws    200 2005-09-05 15:52 ./
drwxrwxr-x  8 andreas outlaws    336 2005-09-05 15:52 ../
lrwxrwxrwx  1 andreas outlaws     21 2005-09-05 15:52 libqwtplot3d.so -> libqwtplot3d.so.0.2.6*
lrwxrwxrwx  1 andreas outlaws     21 2005-09-05 15:52 libqwtplot3d.so.0 -> libqwtplot3d.so.0.2.6*
lrwxrwxrwx  1 andreas outlaws     21 2005-09-05 15:52 libqwtplot3d.so.0.2 -> libqwtplot3d.so.0.2.6*
- -rwxrwxr-x  1 andreas outlaws 390712 2005-09-05 15:52 libqwtplot3d.so.0.2.6*


b) Fresh install of LabPlot-1.5.0.1. The package installs
~   itself under /opt/kde3/

c) Verify LabPlot library dependencies, especially the libLabPlot libraries

andreas@tolstoi:~ {1016} % ldd /opt/kde3/bin/LabPlot
~        libLabPlotnetCDF.so.3 => /opt/kde3/lib/libLabPlotnetCDF.so.3 (0x40017000)
~        libLabPlot.so.1 => /opt/kde3/lib/libLabPlot.so.1 (0x40045000)
~        libgsl.so.0 => /usr/lib/./libgsl.so.0 (0x403a6000)
~        libgslcblas.so.0 => /usr/lib/./libgslcblas.so.0 (0x40524000)
~        libMagick++.so.6 => /usr/lib/./libMagick++.so.6 (0x40555000)
~        libWand.so.6 => /usr/lib/./libWand.so.6 (0x405c0000)
~        libMagick.so.6 => /usr/lib/./libMagick.so.6 (0x405f8000)
~        libltdl.so.3 => /usr/lib/./libltdl.so.3 (0x4080e000)
~        liblcms.so.1 => /usr/lib/./liblcms.so.1 (0x40816000)
~        libtiff.so.3 => /usr/lib/./libtiff.so.3 (0x40845000)
~        libjpeg.so.62 => /usr/lib/./libjpeg.so.62 (0x40894000)
~        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x408d0000)
~        libfftw3.so.3 => /usr/lib/./libfftw3.so.3 (0x40921000)
~        libaudiofile.so.0 => /usr/lib/./libaudiofile.so.0 (0x409b1000)
~        libGLU.so.1 => /usr/lib/./libGLU.so.1 (0x409d8000)
~        libLabPlotqwtplot3d.so.0 => /opt/kde3/lib/libLabPlotqwtplot3d.so.0 (0x40a52000)
~        libkexidbparser.so.0 => /opt/kde3/lib/libkexidbparser.so.0 (0x40aa2000)
~        libkexidb.so.0 => /opt/kde3/lib/libkexidb.so.0 (0x40ab5000)
~        libkdeprint.so.4 => /opt/kde3/lib/libkdeprint.so.4 (0x40b57000)
~        libkparts.so.2 => /opt/kde3/lib/libkparts.so.2 (0x40c2d000)
~        libkio.so.4 => /opt/kde3/lib/libkio.so.4 (0x40c72000)
~        libkdeui.so.4 => /opt/kde3/lib/libkdeui.so.4 (0x40fad000)
~        libkdesu.so.4 => /opt/kde3/lib/libkdesu.so.4 (0x41284000)
~        libkwalletclient.so.1 => /opt/kde3/lib/libkwalletclient.so.1 (0x4129e000)
~        libkdecore.so.4 => /opt/kde3/lib/libkdecore.so.4 (0x412b0000)
~        libDCOP.so.4 => /opt/kde3/lib/libDCOP.so.4 (0x414e8000)
~        libresolv.so.2 => /lib/libresolv.so.2 (0x4151d000)
~        libutil.so.1 => /lib/libutil.so.1 (0x4152f000)
~        libart_lgpl_2.so.2 => /usr/lib/./libart_lgpl_2.so.2 (0x41533000)
~        libidn.so.11 => /usr/lib/./libidn.so.11 (0x41549000)
~        libkdefx.so.4 => /opt/kde3/lib/libkdefx.so.4 (0x41579000)
~        libqt-mt.so.3 => /usr/lib/qt3/lib/libqt-mt.so.3 (0x415a5000)
~        libGL.so.1 => /usr/lib/./libGL.so.1 (0x41c45000)
~        libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x41cb1000)
~        libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x41cc7000)
~        libXcursor.so.1 => /usr/X11R6/lib/libXcursor.so.1 (0x41cca000)
~        libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 (0x41cd3000)
~        libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x41cd6000)
~        libfontconfig.so.1 => /usr/lib/./libfontconfig.so.1 (0x41ce9000)
~        libfreetype.so.6 => /usr/lib/./libfreetype.so.6 (0x41d18000)
~        libexpat.so.0 => /usr/lib/./libexpat.so.0 (0x41d7d000)
~        libdl.so.2 => /lib/libdl.so.2 (0x41d9d000)
~        libpng.so.3 => /usr/lib/./libpng.so.3 (0x41da1000)
~        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x41dd1000)
~        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x41de0000)
~        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x41ea8000)
~        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x41eb1000)
~        libpthread.so.0 => /lib/libpthread.so.0 (0x41ec9000)
~        libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x41f1b000)
~        libz.so.1 => /usr/lib/./libz.so.1 (0x41f23000)
~        libfam.so.0 => /usr/lib/./libfam.so.0 (0x41f36000)
~        libLabPlotcephes.so.1 => /opt/kde3/lib/libLabPlotcephes.so.1 (0x41f3f000)
~        libstdc++.so.5 => /usr/lib/./libstdc++.so.5 (0x41f51000)
~        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4201b000)
~        libm.so.6 => /lib/libm.so.6 (0x42023000)
~        libc.so.6 => /lib/libc.so.6 (0x42046000)
~        libXxf86vm.so.1 => /usr/X11R6/lib/libXxf86vm.so.1 (0x42162000)
~        /lib/ld-linux.so.2 (0x40000000)

andreas@tolstoi:~ {1019} % ll /opt/kde3/lib/libLabPlot*
- -rw-r--r--  1 root root 5734378 2005-09-05 12:14 /opt/kde3/lib/libLabPlot.a
- -rw-r--r--  1 root root  137756 2005-09-05 12:14 /opt/kde3/lib/libLabPlotcephes.a
- -rwxr-xr-x  1 root root     846 2005-09-05 12:01 /opt/kde3/lib/libLabPlotcephes.la*
lrwxrwxrwx  1 root root      25 2005-09-05 16:16 /opt/kde3/lib/libLabPlotcephes.so -> libLabPlotcephes.so.1.5.0*
lrwxrwxrwx  1 root root      25 2005-09-05 16:16 /opt/kde3/lib/libLabPlotcephes.so.1 -> libLabPlotcephes.so.1.5.0*
- -rwxr-xr-x  1 root root   85792 2005-09-05 12:01 /opt/kde3/lib/libLabPlotcephes.so.1.5.0*
- -rwxr-xr-x  1 root root    2002 2005-09-05 12:14 /opt/kde3/lib/libLabPlot.la*
- -rw-r--r--  1 root root  214258 2005-09-05 12:14 /opt/kde3/lib/libLabPlotnetCDF.a
- -rwxr-xr-x  1 root root     846 2005-09-05 12:01 /opt/kde3/lib/libLabPlotnetCDF.la*
lrwxrwxrwx  1 root root      25 2005-09-05 16:16 /opt/kde3/lib/libLabPlotnetCDF.so -> libLabPlotnetCDF.so.3.5.0*
lrwxrwxrwx  1 root root      25 2005-09-05 16:16 /opt/kde3/lib/libLabPlotnetCDF.so.3 -> libLabPlotnetCDF.so.3.5.0*
- -rwxr-xr-x  1 root root  218554 2005-09-05 12:01 /opt/kde3/lib/libLabPlotnetCDF.so.3.5.0*
- -rw-r--r--  1 root root  586906 2005-09-05 12:14 /opt/kde3/lib/libLabPlotqwtplot3d.a
- -rwxr-xr-x  1 root root     891 2005-09-05 12:02 /opt/kde3/lib/libLabPlotqwtplot3d.la*
lrwxrwxrwx  1 root root      28 2005-09-05 16:16 /opt/kde3/lib/libLabPlotqwtplot3d.so -> libLabPlotqwtplot3d.so.0.2.5*
lrwxrwxrwx  1 root root      28 2005-09-05 16:36 /opt/kde3/lib/libLabPlotqwtplot3d.so.0 -> libLabPlotqwtplot3d.so.0.2.5*
- -rwxr-xr-x  1 root root  447962 2005-09-05 12:02 /opt/kde3/lib/libLabPlotqwtplot3d.so.0.2.5*
lrwxrwxrwx  1 root root      19 2005-09-05 16:16 /opt/kde3/lib/libLabPlot.so -> libLabPlot.so.1.5.0*
lrwxrwxrwx  1 root root      19 2005-09-05 16:16 /opt/kde3/lib/libLabPlot.so.1 -> libLabPlot.so.1.5.0*
- -rwxr-xr-x  1 root root 3969232 2005-09-05 12:14 /opt/kde3/lib/libLabPlot.so.1.5.0*

c) Verify, that the original LabPlot still does crash:

andreas@tolstoi:~ {1019} % /opt/kde3/bin/LabPlot
zsh: segmentation fault  /opt/kde3/bin/LabPlot

d) Change the installation to use the new qwtplot3d library

root@tolstoi:~ {621} $ cd /opt/kde3/lib
root@tolstoi:/opt/kde3/lib {622} $ rm libLabPlotqwtplot3d.so.0
/bin/rm: remove symbolic link `libLabPlotqwtplot3d.so.0'? y
root@tolstoi:/opt/kde3/lib {623} $ ln -sf /work/qwtplot3d.new/lib/libqwtplot3d.so.0.2.6 libLabPlotqwtplot3d.so.0
root@tolstoi:/opt/kde3/lib {624} $ ll libLabPlot*
- -rw-r--r--  1 root root 5734378 Sep  5 12:14 libLabPlot.a
- -rwxr-xr-x  1 root root    2002 Sep  5 12:14 libLabPlot.la*
lrwxrwxrwx  1 root root      19 Sep  5 16:16 libLabPlot.so -> libLabPlot.so.1.5.0*
lrwxrwxrwx  1 root root      19 Sep  5 16:16 libLabPlot.so.1 -> libLabPlot.so.1.5.0*
- -rwxr-xr-x  1 root root 3969232 Sep  5 12:14 libLabPlot.so.1.5.0*
- -rw-r--r--  1 root root  137756 Sep  5 12:14 libLabPlotcephes.a
- -rwxr-xr-x  1 root root     846 Sep  5 12:01 libLabPlotcephes.la*
lrwxrwxrwx  1 root root      25 Sep  5 16:16 libLabPlotcephes.so -> libLabPlotcephes.so.1.5.0*
lrwxrwxrwx  1 root root      25 Sep  5 16:16 libLabPlotcephes.so.1 -> libLabPlotcephes.so.1.5.0*
- -rwxr-xr-x  1 root root   85792 Sep  5 12:01 libLabPlotcephes.so.1.5.0*
- -rw-r--r--  1 root root  214258 Sep  5 12:14 libLabPlotnetCDF.a
- -rwxr-xr-x  1 root root     846 Sep  5 12:01 libLabPlotnetCDF.la*
lrwxrwxrwx  1 root root      25 Sep  5 16:16 libLabPlotnetCDF.so -> libLabPlotnetCDF.so.3.5.0*
lrwxrwxrwx  1 root root      25 Sep  5 16:16 libLabPlotnetCDF.so.3 -> libLabPlotnetCDF.so.3.5.0*
- -rwxr-xr-x  1 root root  218554 Sep  5 12:01 libLabPlotnetCDF.so.3.5.0*
- -rw-r--r--  1 root root  586906 Sep  5 12:14 libLabPlotqwtplot3d.a
- -rwxr-xr-x  1 root root     891 Sep  5 12:02 libLabPlotqwtplot3d.la*
lrwxrwxrwx  1 root root      28 Sep  5 16:16 libLabPlotqwtplot3d.so -> libLabPlotqwtplot3d.so.0.2.5*
lrwxrwxrwx  1 root root      45 Sep  5 16:39 libLabPlotqwtplot3d.so.0 -> /work/qwtplot3d.new/lib/libqwtplot3d.so.0.2.6*
- -rwxr-xr-x  1 root root  447962 Sep  5 12:02 libLabPlotqwtplot3d.so.0.2.5*

e) Start LabPlot again

andreas@tolstoi:~ {1020} % /opt/kde3/bin/LabPlot
LabPlot: MainWin()
LabPlot: MainWin::readConfig()
LabPlot: MainWin::New()
LabPlot: MainWin::updateSheetList()
LabPlot: MainWin::updateGraphList()
LabPlot:        number of windows = 0
LabPlot:        NO SHEET/PLOT
LabPlot: MainWin::updateSheetList() DONE

- -> NO CRASH!
(I even verified that QWT plots still do work... ;-)


To me this looks like a valid test that the problem is solved.
What do you think?
What was the reason for the problem?
What did you change?

- - andreas

- --
Andreas Haumer                     | mailto:an...@xs...
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDHFpixJmyeGcXPhERAgrKAJsEt4ivuA7tBYRfW0qtBDLM0qHbjgCfZA8S
+Cxxkx5YnpPEXBENQXACmOY=
=8Pek
-----END PGP SIGNATURE-----

Re: SIGSEGV from qwt3diodummy constructor

[Micha B. <kri...@us...>]

Monday, September 5, 2005, 14:09:28, Andreas Haumer wrote:

http://qwtplot3d.sourceforge.net/050904plot3d.tgz

> Does not compile... :-(

Ooops, erroneous uploaded. My mistake :-(
I've replaced the archive by the correct sources now (unchanged URL)

Micha

Re: SIGSEGV from qwt3diodummy constructor

[Andreas H. <an...@xs...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Micha Bieber schrieb:
| http://qwtplot3d.sourceforge.net/050904plot3d.tgz
|
| contains a modified snapshot of the upcoming version 0.2.6. The relevant
| change addresses the crash from this topic.

Does not compile... :-(

qwtplot3d.pro does not list the sources to be compiled,
so it creates an empty library file...

I modified qwtplot3d.pro to contain the sources from the
old version (don't know if this is correct, though), but
then compilation fails with:

[...]
g++ -c -pipe -fno-exceptions -Wall -W -g -D_REENTRANT -fPIC  -DGL2PS_HAVE_ZLIB -DQT_THREAD_SUPPORT -DQT_SHARED -DQT_NO_DEBUG -I/usr/lib/qt3/mkspecs/default -I. -Iinclude -I/usr/lib/qt3/include -I/usr/X11R6/include -Itmp/ -o tmp/qwt3d_gridplot.o src/qwt3d_gridplot.cpp
src/qwt3d_gridplot.cpp: In member function `void
~   Qwt3D::GridPlot::Isolines2Floor()':
src/qwt3d_gridplot.cpp:430: error: `drawIntersection' undeclared (first use
~   this function)
src/qwt3d_gridplot.cpp:430: error: (Each undeclared identifier is reported only
~   once for each function it appears in.)
src/qwt3d_gridplot.cpp: In member function `virtual void
~   Qwt3D::GridPlot::createOpenGlData()':
src/qwt3d_gridplot.cpp:488: error: `createPoints' undeclared (first use this
~   function)
src/qwt3d_gridplot.cpp:622:2: warning: no newline at end of file
make: *** [tmp/qwt3d_gridplot.o] Error 1

| No problems here so far with WinXP and gentoo for qt 3.3.4/4.0.1
| Please could someone check with affected applications/systems or/and
| give me a hint regarding a combination reproducing the phenomenon.
| (e.g. Slackware ?.? / qt ?.?.? / LabPlot ?.?).
| It has to be something I'm able to set up in a virtual VMWare machine
| (most linuxes should do).
|
As far as I'm informed, there were reports of this problem
on Slackware 10.1 (see thread https://sourceforge.net/mailarchive/forum.php?thread_id=7680236&forum_id=41120)
and YOPER 2.0, was well as our own Linux distribution (BLD-5.2)

I was testing with LabPlot-1.5.0 and 1.5.0.1, which both
contain a copy of qwtplot3d-0.2.5

I can give you an SSH account on one of our development
machines if you want to test this on our Linux version.

- - andreas

- --
Andreas Haumer                     | mailto:an...@xs...
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDHDVrxJmyeGcXPhERAjRfAJ4lH3/I0e845SsjWE8wUIsoLjKneACeLhiY
n/21wEcW2cUs34pwAjZ7QpY=
=zNo6
-----END PGP SIGNATURE-----

Re: Why is plot shifting limited to [-1..1] and is there a workaround?

[Micha B. <kri...@us...>]

Adam,

please look for

qwt3d_movements.cpp:
void Plot3D::setViewportShift( double xVal, double yVal )

and change the 'limit' variable to something larger (or remove them and
the related if-statements completely). The parameter creates the
mentioned 'wall'. To be honest, I cannot remember exactly what in the
past the reason for introducing the limitation was ..
Caused by a more unpleasing old error, the release for version 0.2.6
might be on hold for a few days, but I'll eventually move the change
into the final version too.

Micha  
-- 

Re: SIGSEGV from qwt3diodummy constructor

[Micha B. <kri...@us...>]

http://qwtplot3d.sourceforge.net/050904plot3d.tgz

contains a modified snapshot of the upcoming version 0.2.6. The relevant
change addresses the crash from this topic.
No problems here so far with WinXP and gentoo for qt 3.3.4/4.0.1
Please could someone check with affected applications/systems or/and
give me a hint regarding a combination reproducing the phenomenon.
(e.g. Slackware ?.? / qt ?.?.? / LabPlot ?.?).
It has to be something I'm able to set up in a virtual VMWare machine
(most linuxes should do).

Micha  
-- 

Re: SIGSEGV from qwt3diodummy constructor

[Andreas H. <an...@xs...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Micha!

Thanks for your reply!

Micha Bieber schrieb:
|>I am not too familiar with qwt_plot3d and have no experience with labplot,
|>but the type of error looks to me like a typical mismatch of different Qt
|>versions.
|
|
| Perhaps true, but I'll do my guess work too.
| I've introduced the dummy variable in the past, because I received the
| same kind of crash when producing a qwt3d Windows dll in VC6 _without_
| the variable declared. The IO object is a singleton, created on the fly

oh... :-(

| inside 'static Container& wlist()' and I suspect something goes wrong here
| with global object destruction.
| I plan to release a version of qwt3d this weekend and will make an
| attempt again to understand what happens when it comes to dll's.
| I don't like this specific kind of uncertainty (or my missing knowledge)
| anyway, so its a good time to delve in again...
|

Very true.

By removing the variable I managed to eliminate the crash,
but I still do not know why the crash happens in the first
place and that makes me nervous.

There are Linux systems out there where the crash does not
happen at all. And as far as I know there are at least
three different Linux distributions (Slackware as the most
prominent amongst them) where the crash occurs.

And it also seems to be dependent on the application:
for me, the crash occurs with LabPlot only, while the
qwtplot3d example applications like simpleplot or mesh2
work just fine, even with the qwt3diodummy variable in
place. I have yet to find a simple example application
where I can reproduce the problem. This is weird!

- - andreas

- --
Andreas Haumer                     | mailto:an...@xs...
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDGdW0xJmyeGcXPhERAvu5AKCAgYd0krTRy8IEFQAjm7q0iW95nQCfTWSk
WUS5NRMi1VN2DZjEGFTRp/o=
=jAJG
-----END PGP SIGNATURE-----

Re: SIGSEGV from qwt3diodummy constructor

[Andreas H. <an...@xs...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Stefan!

Thanks for your response!

Stefan Blum schrieb:
| Hi Andreas,
|
| as any help is appreciated ...
|
| I am not too familiar with qwt_plot3d and have no experience with labplot,
| but the type of error looks to me like a typical mismatch of different Qt
| versions. Make sure that you have compiled  and linked every single piece
| with the _same_ Qt version (perhaps including KDE). And, it is worth
| noting that different linux platforms will use different Qt versions. You
| probaly will have to let the compiler run on each single installation. To
| see the library dependencies, use ldd + executable/shared object.
|
In my case the whole system was compiled by myself from
sources a few days ago, as we use our own Linux distribution
here. So I know for sure that KDE, LabPlot etc. was compiled
against the very same QT library (version 3.3.4).

During my tests I recompiled LabPlot, Qt and qwtplot3d
several times with different compile options, just to
get something what I would call "differential diagnosis":
slightly change some well defined parts of the system until
you get a different outcome. Then you know which part is
responsible for it. But in this case I _always_ got the same
result: it always crashes in the constructor of Qwt3d::IO on
access to the QString::null object.

If it was a library mismatch, I think I would have seen
at least some difference in behaviour during those many
compile runs...

- - andreas

- --
Andreas Haumer                     | mailto:an...@xs...
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDGdG7xJmyeGcXPhERAtBzAJ9zINj8Gh8NgJ2vpSl8o+9GwrHpDQCgh+hm
V71RHwp7UswMCApBxMjO0iA=
=5uMi
-----END PGP SIGNATURE-----

Re: SIGSEGV from qwt3diodummy constructor

[Micha B. <kri...@us...>]

> I am not too familiar with qwt_plot3d and have no experience with labplot,
> but the type of error looks to me like a typical mismatch of different Qt
> versions.

Perhaps true, but I'll do my guess work too.
I've introduced the dummy variable in the past, because I received the
same kind of crash when producing a qwt3d Windows dll in VC6 _without_
the variable declared. The IO object is a singleton, created on the fly
inside 'static Container& wlist()' and I suspect something goes wrong here
with global object destruction.
I plan to release a version of qwt3d this weekend and will make an
attempt again to understand what happens when it comes to dll's.
I don't like this specific kind of uncertainty (or my missing knowledge)
anyway, so its a good time to delve in again...

Micha

Re: SIGSEGV from qwt3diodummy constructor

[Stefan B. <bl...@lp...>]

Hi Andreas,

as any help is appreciated ...

I am not too familiar with qwt_plot3d and have no experience with labplot,
but the type of error looks to me like a typical mismatch of different Qt
versions. Make sure that you have compiled  and linked every single piece
with the _same_ Qt version (perhaps including KDE). And, it is worth
noting that different linux platforms will use different Qt versions. You
probaly will have to let the compiler run on each single installation. To
see the library dependencies, use ldd + executable/shared object.

Hope that helps.

Stefan

Andreas Haumer wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi!
>
> I found a very strange problem which I'm hunting for a few
> days now and as it has some connection to qwtplot3d I'd like
> to extend the discussion to this list. I'd really appreciate
> your help!
>
> A few days ago I found this nice QT/KDE application LabPlot
> (http://labplot.sourceforge.net/) which uses qwtplot3d to
> draw 3D plots of data and functions. When I first tried this
> application, it did a SIGSEGV right from the beginning. It
> turned out this was a known problem for some time, but no
> one found a real solution yet.
>
> I decided to dig into the problem and found, that the crash
> occurs in the constructor for variable qwt3diodummy, defined
> in file qwt3d_io.cpp:
>
> static Qwt3D::IO qwt3diodummy; // Don't delete !
>
>
> The crash itself occurs deep inside the QT library when
> accessing a QString object which does not seem to be
> initialized correctly.
>
> A gdb backtrace of the crashed application shows the following:
>
> (gdb) r
> Starting program: /opt/kde3/bin/LabPlot
> [Thread debugging using libthread_db enabled]
> [New Thread 16384 (LWP 20230)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 20230)]
> 0x41ac3e6d in QString::operator= () from /usr/lib/./libqt-mt.so.3
> (gdb) bt
> #0  0x41ac3e6d in QString::operator= () from /usr/lib/./libqt-mt.so.3
> #1  0x41a9eebb in QDir::QDir () from /usr/lib/./libqt-mt.so.3
> #2  0x41aabb34 in QGPluginManager::addLibraryPath () from
/usr/lib/./libqt-mt.so.3
> #3  0x41aab6c2 in QGPluginManager::QGPluginManager () from
/usr/lib/./libqt-mt.so.3
> #4  0x417f1e22 in qt_init_image_plugins () from /usr/lib/./libqt-mt.so.3
> #5  0x417f283e in QImageIO::outputFormats () from /usr/lib/./libqt-mt.so.3
> #6  0x417f0e61 in QImage::outputFormatList () from /usr/lib/./libqt-mt.so.3
> #7  0x40a850d2 in Qwt3D::IO::setupHandler () from
/opt/kde3/lib/libLabPlotqwtplot3d.so.0
> #8  0x40a85888 in __static_initialization_and_destruction_0 () from
/opt/kde3/lib/libLabPlotqwtplot3d.so.0
> #9  0x40a85a2b in global constructors keyed to
_ZN5Qwt3D2IO18defineInputHandlerERK7QStringPFbPNS_6Plot3DES3_E () from
/opt/kde3/lib/libLabPlotqwtplot3d.so.0
> #10 0x40aa3027 in __do_global_ctors_aux () from
/opt/kde3/lib/libLabPlotqwtplot3d.so.0
> #11 0x40a65af5 in _init () from /opt/kde3/lib/libLabPlotqwtplot3d.so.0
> #12 0x4000aefe in call_init () from /lib/ld-linux.so.2
> #13 0x4000afe6 in _dl_init_internal () from /lib/ld-linux.so.2
> #14 0x400007df in _dl_start_user () from /lib/ld-linux.so.2
>
> The crash does occur on a few Linux systems only and you
> can avoid it by removing or renaming the QT plugin directory
> (e.g. "/usr/lib/qt3/plugins/"). Needless to say that this is
> not a proper technical solution.
>
> You can also avoid the problem by removing the variable
> qwt3diodummy from the qwtplot3d library, as in that case
> the constructor is not called at the program's initialization.
> Calling the constructor for a Qwt3D::IO object later on in
> the programs life does not trigger the crash.
>
> Now I do not really know the purpose of this variable and the
> "Don't delete !" comment makes me a little bit nervous about
> touching this part of the library, but it seems that removing
> the variable does not have any ill effect to the application.
>
> You can find more in-depth information about the problem
> in thread " LabPlot-1.5.0.1 segfault with qt3" on the
> LabPlot mailing list (see
http://sourceforge.net/mailarchive/forum.php?thread_id=8067085&forum_id=41120)
> as well as a report I sent to the qt-interest mailing list
> (see http://lists.trolltech.com/qt-interest/2005-09/thread00108-0.html)
>
> In those mails I described everything I currently know about
> the problem and also some discussion about it with the
> maintainer of the LabPlot application.
>
> As I up to now could not find an obvious bug in any of the
> sources, my current theory about the problem is that it might
> be a bug in the way the LabPlot application is compiled and/or
> linked or it might even be a bug in the Linux tool chain
> (gcc/g++, binutils, linker/loader). But I really can't prove
> it yet!
>
> Now my questions are:
>
> *) Does anybody know more about this problem?
>
> *) Does anybody know how to solve it in a clean way?
>
> *) What is the purpose of variable qwt3diodummy?
> ~   Can it be removed from the qwtplot3d library
> ~   so we can work around the crash?
>
> Any help is appreciated!
>
> - - andreas
>
> - --
> Andreas Haumer                     | mailto:an...@xs...
> *x Software + Systeme              | http://www.xss.co.at/
> Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
> A-1100 Vienna, Austria             | Fax: +43-1-6060114-71
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFDGbEAxJmyeGcXPhERAomJAJ0XuB/T/BoflFVfaSO+XFMedLxFggCfQfc6
> WSfL9ZnFqOorfirMZfbPjz8=
> =xprk
> -----END PGP SIGNATURE-----
>
>
>

SIGSEGV from qwt3diodummy constructor

[Andreas H. <an...@xs...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

I found a very strange problem which I'm hunting for a few
days now and as it has some connection to qwtplot3d I'd like
to extend the discussion to this list. I'd really appreciate
your help!

A few days ago I found this nice QT/KDE application LabPlot
(http://labplot.sourceforge.net/) which uses qwtplot3d to
draw 3D plots of data and functions. When I first tried this
application, it did a SIGSEGV right from the beginning. It
turned out this was a known problem for some time, but no
one found a real solution yet.

I decided to dig into the problem and found, that the crash
occurs in the constructor for variable qwt3diodummy, defined
in file qwt3d_io.cpp:

static Qwt3D::IO qwt3diodummy; // Don't delete !


The crash itself occurs deep inside the QT library when
accessing a QString object which does not seem to be
initialized correctly.

A gdb backtrace of the crashed application shows the following:

(gdb) r
Starting program: /opt/kde3/bin/LabPlot
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 20230)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 20230)]
0x41ac3e6d in QString::operator= () from /usr/lib/./libqt-mt.so.3
(gdb) bt
#0  0x41ac3e6d in QString::operator= () from /usr/lib/./libqt-mt.so.3
#1  0x41a9eebb in QDir::QDir () from /usr/lib/./libqt-mt.so.3
#2  0x41aabb34 in QGPluginManager::addLibraryPath () from /usr/lib/./libqt-mt.so.3
#3  0x41aab6c2 in QGPluginManager::QGPluginManager () from /usr/lib/./libqt-mt.so.3
#4  0x417f1e22 in qt_init_image_plugins () from /usr/lib/./libqt-mt.so.3
#5  0x417f283e in QImageIO::outputFormats () from /usr/lib/./libqt-mt.so.3
#6  0x417f0e61 in QImage::outputFormatList () from /usr/lib/./libqt-mt.so.3
#7  0x40a850d2 in Qwt3D::IO::setupHandler () from /opt/kde3/lib/libLabPlotqwtplot3d.so.0
#8  0x40a85888 in __static_initialization_and_destruction_0 () from /opt/kde3/lib/libLabPlotqwtplot3d.so.0
#9  0x40a85a2b in global constructors keyed to _ZN5Qwt3D2IO18defineInputHandlerERK7QStringPFbPNS_6Plot3DES3_E () from /opt/kde3/lib/libLabPlotqwtplot3d.so.0
#10 0x40aa3027 in __do_global_ctors_aux () from /opt/kde3/lib/libLabPlotqwtplot3d.so.0
#11 0x40a65af5 in _init () from /opt/kde3/lib/libLabPlotqwtplot3d.so.0
#12 0x4000aefe in call_init () from /lib/ld-linux.so.2
#13 0x4000afe6 in _dl_init_internal () from /lib/ld-linux.so.2
#14 0x400007df in _dl_start_user () from /lib/ld-linux.so.2

The crash does occur on a few Linux systems only and you
can avoid it by removing or renaming the QT plugin directory
(e.g. "/usr/lib/qt3/plugins/"). Needless to say that this is
not a proper technical solution.

You can also avoid the problem by removing the variable
qwt3diodummy from the qwtplot3d library, as in that case
the constructor is not called at the program's initialization.
Calling the constructor for a Qwt3D::IO object later on in
the programs life does not trigger the crash.

Now I do not really know the purpose of this variable and the
"Don't delete !" comment makes me a little bit nervous about
touching this part of the library, but it seems that removing
the variable does not have any ill effect to the application.

You can find more in-depth information about the problem
in thread " LabPlot-1.5.0.1 segfault with qt3" on the
LabPlot mailing list (see http://sourceforge.net/mailarchive/forum.php?thread_id=8067085&forum_id=41120)
as well as a report I sent to the qt-interest mailing list
(see http://lists.trolltech.com/qt-interest/2005-09/thread00108-0.html)

In those mails I described everything I currently know about
the problem and also some discussion about it with the
maintainer of the LabPlot application.

As I up to now could not find an obvious bug in any of the
sources, my current theory about the problem is that it might
be a bug in the way the LabPlot application is compiled and/or
linked or it might even be a bug in the Linux tool chain
(gcc/g++, binutils, linker/loader). But I really can't prove
it yet!

Now my questions are:

*) Does anybody know more about this problem?

*) Does anybody know how to solve it in a clean way?

*) What is the purpose of variable qwt3diodummy?
~   Can it be removed from the qwtplot3d library
~   so we can work around the crash?

Any help is appreciated!

- - andreas

- --
Andreas Haumer                     | mailto:an...@xs...
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDGbEAxJmyeGcXPhERAomJAJ0XuB/T/BoflFVfaSO+XFMedLxFggCfQfc6
WSfL9ZnFqOorfirMZfbPjz8=
=xprk
-----END PGP SIGNATURE-----

RE: Why is plot shifting limited to [-1..1] and is there a workaround?

[Adam G. <ag...@in...>]

Thanks for the response. I'll keep an eye out for 0.2.6. -Adam

________________________________

From: qwt...@li... on behalf of Micha =
Bieber
Sent: Sun 8/28/2005 6:49 AM
To: Adam Gurson
Subject: Re: Why is plot shifting limited to [-1..1] and is there a =
workaround?



Thursday, August 25, 2005, 18:52:56, Adam Gurson wrote:

> When shifting a view that has not been zoomed, this works great.
> However, if the user zooms in on the view and then attempts to shift,
> they hit an invisible "wall" when trying to shift to the end of the

I have to admit, this error is a 'skeleton in my closet'. It's very
probably fixed for version 0.2.6 (Qt 4.0.1 adaption, release next
weekend).
I'll give you a hint, if the change makes it into cvs beforehand.

Micha



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle =
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & =
QA
Security * Process Improvement & Measurement * =
http://www.sqe.com/bsce5sf
_______________________________________________
qwtplot3d-interest mailing list
qwt...@li...
https://lists.sourceforge.net/lists/listinfo/qwtplot3d-interest

Re: Why is plot shifting limited to [-1..1] and is there a workaround?

[Micha B. <kri...@us...>]

Thursday, August 25, 2005, 18:52:56, Adam Gurson wrote:

> When shifting a view that has not been zoomed, this works great.
> However, if the user zooms in on the view and then attempts to shift,
> they hit an invisible "wall" when trying to shift to the end of the

I have to admit, this error is a 'skeleton in my closet'. It's very
probably fixed for version 0.2.6 (Qt 4.0.1 adaption, release next
weekend).
I'll give you a hint, if the change makes it into cvs beforehand.

Micha

Why is plot shifting limited to [-1..1] and is there a workaround?

[Adam G. <ag...@in...>]

I am writing a program that allows a user to view terrain in 3D. I am
using a derivative of Plot3D, which uses the built-in ability to shift
(pan) the view. The Plot3D::setViewportShift(), which handles the
shifting, function states that the function "Performs shifting along
screen axes. The values are limited to the interval [-1..1]. The shift
moves points inside a sphere, which encloses the unscaled and unzoomed
data by multiples of the spheres diameter."=20

=20

When shifting a view that has not been zoomed, this works great.
However, if the user zooms in on the view and then attempts to shift,
they hit an invisible "wall" when trying to shift to the end of the
zoomed view because the Plot3D::setViewportShift() does not take zooming
into effect a limits the shifting from -1 to 1. The result is the
inability to view some portions of the terrain when zoomed in because
the shift prevents shifting far enough to see it. This is easy to
reproduce: Load up the mesh2 example, zoom in on one of the shapes and
then attempt to shift it off the screen. It won't work because of this
limitation.

=20

Is there a reason that this [-1..1] limitation is in effect? Is there a
way to workaround this so that I can allow users to see all parts of the
terrain when zoomed in by shifting? Any help would be much appreciated.
Thank you.

Windows and other things

[Jeremy M. <je...@bi...>]

Thanks for all the help. If you ever want to compile QWT Plot 3d with
Borland C++ 6 you will have to edit gl2ps.c and add #include <windows.h>.
With that solved, I have 2 more issues:

1. Trying to compile it on Debian 3.0 for Sparc and I get this error:

Qwt3D::Arrow::calcRotation(Qwt3D::Triple&, const Qwt3D::FreeVector&)';
src/qwt3d_enrichment_std.cpp:346: error: `PI' undeclared in namespace `Qwt3D'

Qt 3.3.4, Qwt 4.2.0rc2, GCC 3.3.5

2. Another compilation on OpenBSD 3.6 fails with OpenGL errors.

Has anybody tried to compile it on these systems?

Thanks for any ideas...


-- 
Jeremy Mann
je...@bi...

University of Texas Health Science Center
Bioinformatics Core Facility
http://www.bioinformatics.uthscsa.edu
Phone: (210) 567-2672

Re: Compiling with Borland 6

[Micha B. <kri...@us...>]

Running google I recognized, that the Borland/OpenGL couple caused the problem
now and then:

http://tinyurl.com/dgedq

Maybe this is helpful for you, yet the first few topics seem to deal
with something looking very similar at the first glance.

I think, you have better chances (having the Borland compiler installed)
than me to check the different possibilities and to come out with a
solution. But of course, ask again if it smells more like a qwt3d caused
problem again :)

Please drop me your findings, if I can do something in re-organizing the
code in order to make bcc/c++-builder happy.

Micha

Re: Compiling with Borland 6

[Jeremy M. <je...@bi...>]

Thanks for the quick response Micha.

Micha Bieber said:

> if you could provide me with some (one) of the offending language
> construct/s in your gl.h version I'm perhaps able to make a more precise
> guess.

I won't copy/paste all the lines but here is starting at line 1152 which
is part of the error:

WINGDIAPI void APIENTRY glAccum (GLenum op, GLfloat value);
WINGDIAPI void APIENTRY glAlphaFunc (GLenum func, GLclampf ref);
WINGDIAPI GLboolean APIENTRY glAreTexturesResident (GLsizei n, const
GLuint *textures, GLboolean *residences);
WINGDIAPI void APIENTRY glArrayElement (GLint i);
WINGDIAPI void APIENTRY glBegin (GLenum mode);
WINGDIAPI void APIENTRY glBindTexture (GLenum target, GLuint texture);
WINGDIAPI void APIENTRY glBitmap (GLsizei width, GLsizei height, GLfloat
xorig, GLfloat yorig, GLfloat xmove, GLfloat ymove, const GLubyte
*bitmap);
WINGDIAPI void APIENTRY glBlendFunc (GLenum sfactor, GLenum dfactor);
WINGDIAPI void APIENTRY glCallList (GLuint list);
WINGDIAPI void APIENTRY glCallLists (GLsizei n, GLenum type, const GLvoid
*lists);
WINGDIAPI void APIENTRY glClear (GLbitfield mask);
WINGDIAPI void APIENTRY glClearAccum (GLfloat red, GLfloat green, GLfloat
blue, GLfloat alpha);
WINGDIAPI void APIENTRY glClearColor (GLclampf red, GLclampf green,
GLclampf blue, GLclampf alpha);
WINGDIAPI void APIENTRY glClearDepth (GLclampd depth);
WINGDIAPI void APIENTRY glClearIndex (GLfloat c);
WINGDIAPI void APIENTRY glClearStencil (GLint s);

> BTW, what is your qwt3d and Qt version ?

QwtPlot3d 2.5 and Qt 3.3.4 Windows Commercial.

Thanks for any help you can give!


-- 
Jeremy Mann
je...@bi...

University of Texas Health Science Center
Bioinformatics Core Facility
http://www.bioinformatics.uthscsa.edu
Phone: (210) 567-2672

Re: Compiling with Borland 6

[Micha B. <kri...@us...>]

Monday, August 15, 2005, 23:24:39, Jeremy Mann wrote:

> Borland

I received the question from another member of your team (?)
some hours ago, so my forwarded answer here:

Monday, August 15, 2005, 19:43:38, Yu Ning wrote:

> Hi Michael,

> I try to use the Borland C++ builder 6 to complie the qwtplot3d, get the
> following error message. Could you please give some advice how to get it
> pass? thanks-Yu

Difficult, not having the C++ builder at hand, but

> 3rdparty\gl2ps\gl2ps.c:
> Error E2141 C:\Program Files\Borland\CBuilder6\Include\GL/gl.h 1152:
> Declaration syntax error

if you could provide me with some (one) of the offending language
construct/s in your gl.h version I'm perhaps able to make a more precise
guess.

BTW, what is your qwt3d and Qt version ?

Micha  
-- 

Compiling with Borland 6

[Jeremy M. <je...@bi...>]

Good afternoon. I am trying to compile QwtPlot3d 2.5 on an XP machine with
Borland C++ Builder 6. I get definition errors from Borland's gl.h include
file. I'm curious since the developer includes a Visual Studio build file,
if MS OpenGL includes are different from Borland?

The error is from line 1152 to 1176 in Borland's gl.h file I get
"Declaration Syntax Error" and make quits.

Any ideas?




-- 
Jeremy Mann
je...@bi...

University of Texas Health Science Center
Bioinformatics Core Facility
http://www.bioinformatics.uthscsa.edu
Phone: (210) 567-2672

Re: Label background colo

[Micha B. <kri...@us...>]

Friday, July 22, 2005, 20:37:52, Keith, Todd wrote:

> Actually, it looks like simply NOT calling pm_.fill() [which is the
> same as pm_.fill(Qt:;white)] at all should and does work for both Qt3
> and Qt4.

I think to remember (still not sure about this anymore), that I got
drawing errors seemingly caused by uninitialized background (despite the
masks existence) for some graphic-card/Qt-version combination at the
time, when I wrote the code (Qt3.0.?). This behavior was fixable by
introducing the artificial fill.
I think, the pixmap should respect the mask also in the case of a filling
operation. IMO, the whole mask/alpha-channel topic has not yet a completely
unmisleading solution in Qt4.
For general clarification, I filed a (pending) bug report to Trolltech.

Micha  
-- 

Re: Label background colo

[Keith, T. <ke...@um...>]

Actually, it looks like simply NOT calling pm_.fill() [which is the same =
as pm_.fill(Qt:;white)] at all should and does work for both Qt3 and =
Qt4.  Why is pm_.fill() there?  The non-text pixels are defined by the =
mask to be transparent and the text pixels are defined by the mask to be =
opaque and are painted explicitly on the pixmap ... but I agree that the =
behavior of QPixmap::fill() wrt to the mask has changed between Qt3 and =
Qt4 ...

Re: Label background color

[Micha B. <kri...@us...>]

Friday, July 22, 2005, 00:33:03, Keith, Todd wrote:

> I'm using qt-win-commercial-src-4.0.1-snapshot-20050721.zip and the latest qwtplot3d-0.2.5

> In Label::update(), I found it necessary to do the following to
> avoid a white label background (which is undesirable if plot
> background color is not white)

Yes, the error is stated in the 0.2.5 release notes. I'm still not
satisfied with the fact, that label masks doesn't work as in Qt3. I got
no answer so far for my related question in Qt4-interest (or was it
qt4-feedback?). I'll continue to get a cleaner solution from Trolltech.
In any case, I'll eventually implement some solution.

Label background color

[Keith, T. <ke...@um...>]

I'm using qt-win-commercial-src-4.0.1-snapshot-20050721.zip and the =
latest qwtplot3d-0.2.5

In Label::update(), I found it necessary to do the following to avoid a =
white label background (which is undesirable if plot background color is =
not white)

pm_.setMask(bm);

GLdouble col[4];

glGetDoublev(GL_COLOR_CLEAR_VALUE, col);

pm_.fill(GL2Qt(col[0], col[1], col[2]));