Bug#329231: Qt change brings to light bug in kst

[Josh Metzler <joshdeb@metzlers.org>]

reassign 329231 kst
found 329231 1.1.0-2.1
thanks

Mark,

I just spent some time investigating this bug, and here is what I found:

The two line change you propose to revert in qt is the only change in 
qpixmap.cpp or qpixmap_x11.cpp from qt 3.3.4 to 3.3.5.  In the changes 
file <http://www.trolltech.com/developer/changes/changes-3.3.5.html> I 
read this:

- QPixmap
        Fixed a crash when loading a cursor from an embedded image.
        The color depth is now set properly when converting a QBitmap.

Even though this is in the "Mac" section of the changes file, this makes me 
reluctant to revert the change.

When I look at the qt 3.3 API docs for QPixmap constructors 
<http://doc.trolltech.com/3.3/qpixmap.html#QPixmap-3>, I read:

The depth can be either 1 (monochrome) or the depth of the current video 
mode. If depth is negative, then the hardware depth of the current video 
mode will be used.

Finally, I ran kst under gdb with qt-x11-free-dbg installed and set a 
breakpoint at QPixmap::init just before creating a plot.  After lots of 
continues with valid parameters (w or h is 0 and depth is 0, or depth is 
-1 or 24 on my display), I got one with depth set to 8.  This doesn't 
cause a problem here because w = h = 0, so a null pixmap of depth 8 is 
created.  When it is resized, however, it causes a problem.  With the old 
qt behavior, an invalid depth was ignored when creating a null pixmap.

So, the bug is in lines 84, 124, 389 of kst/kst/kst2dplot.cpp where it 
specifies a depth of 8 when creating the KstBackBuffer.  It should 
probably use the default of -1 and let qt create a QPixmap of the 
appropriate bit depth.

Josh