Version: (using KDE 4.2.4) OS: Linux Installed from: Unlisted Binary Package I'm not sure if this is oxygens fault, but I'm seeing an odd red tint in places. I have screenshots I'll attach with what I'm seeing in the frame around the konversation 1.2alpha2 tree based "tabs" as well as two buttons in the akregator integrated web browser (khtml?) showing a page from slashdot. I've seen it in a couple of other weird spots as well, but I did not think to take screen grabs. There was a border in the yakuake config dialog that had this at some point. I do not see this behavior on my laptop which uses intel graphics. My desktop, where I see this effect, is using the 180.51 nvidia graphics driver.
Created attachment 34337 [details] konversation 1.2alpha2 example
Created attachment 34338 [details] akregator web browser showing slashdot example
Created attachment 34488 [details] Checkboxes at: http://www.qtsoftware.com/downloads/linux-x11-cpp I'm running the most current nvidia beta driver in this screenshot. I'm not sure if it's even a driver issue. I'm at a loss of even how to begin searching for what's causing this.
Created attachment 34490 [details] Frame in Shaman package manager last one, I promise
Created attachment 34707 [details] system settings > appearance -> colors -> disabled I went digging through the KDE/Qt code to try to find the source of this. I started with the Konversation custom widget which is based on the K3ListView. I tracked the frame drawing code to Q3Frame which uses an internal function in QFrame to do the drawing. This uses the Dark color role to determine the color to add a sunken effect. Which leads to the attached file... The image is from the Disabled tab of the Colors section of the Appearance system settings category. The pink area is White when Intensity is set to None. Setting it to Darken causes the green and blue values to be decreased, but red remains at 255 causing the pink you see. I believe this is related to the rest. How it is related or why this is happening is still beyond my reach. I will continue looking, but some pointers would be much appreciated. The Qt Brush/Palette/Color code is unexpectedly complicated.
Created attachment 34708 [details] test case The culprit appears to be KColorUtils::darker. The attachment contains a bare minimum test case. I attempt to darken (255,255,255) by 0.1. The test program prints the RGB value of the color before and after darken. The output is as follows: [mrgrim@mrgrim tmp]$ ./qcolor 255 255 255 255 240 240 I've tested this on KDE 4.2.4 and Qt 4.5.1
Thanks for invesigating. Trouble is that the bug is assigned to the wrong people. Try to contact Matthew Woehlke. He is the person I hope will be able to shed some light on this.
Fortunately I noticed http://reviewboard.kde.org/r/868/ posted to k-c-d. If you like, please check if my suggested fix works for you. Hopefully we will get this patched soon :-). (In the future, please just CC me or (if bugzilla allows it) add me to the bug's CC list. Or, you know, assign it to me ;-). For something like this, I don't mind!) FWIW the "why" in said patch sounds correct.
SVN commit 985441 by mwoehlke: KHCY: Fix chroma calculation for grays which is sometimes (depends on compile flags) broken due to FP omtimizations. Improve kcolorutils test to catch these. This should fix the pink/red tint glitches that have been reported. Some other QCOMPARE's in the test case are also adjusted (expected/actual values were swapped, and whitespace was wrong). Many thanks to Michael Kreitzer for the analysis. BUG: 194703 BUG: 195522 M +1 -1 colors/kcolorspaces.cpp M +34 -4 tests/kcolorutilstest.cpp M +1 -0 tests/kcolorutilstest.h WebSVN link: http://websvn.kde.org/?view=rev&revision=985441