Version: unspecified (using KDE 4.7.1) OS: Linux When using the dropper tool on kcolorchooser to pick a color from the screen, the color selected is always too dark. Reproducible: Didn't try Steps to Reproduce: Create a simple html page <html> <body style="background-color:#ff0000"></body> </html> Then open this file in a web browser, open kcolorchooser and click the dropper tool and then click the browser window. Actual Results: The color selected in the application is #D50707 Expected Results: The selected color should be #FF0000
I think this is probably because I have the dim inactive windows configuration value set
I guess it could be possible to use the kwin snapshot plugin/effect to grab the color of a single pixel.
I'd propose to add a timeout instead. Ratio: -------- a) There is no bug - you got what you picked, the color is *not* "too dark", but the screen condition is not the one your wanted. What if somebody actually wants to pick the color he currently sees? (sounds like a reasonable wish to me ;-) b) if you've installed chromium, try to pick the color of the active tabbar background - same goes for widgets styles desaturating the highlight color of deactivated windows. The snapshot effect won't help you at all. c) try to pick the color of any item that changes on hover (buttons, scrollbars) - dto. The delay offers more freedom, because you can still use the system to get the screen into the state you want, wait, click. KSnapshot has one and we've added one even to the window detector in the window rules (to detect eg. fullscreen windows)
> get the screen into the state you want, wait, click That's exactly how the color picker works. When you click on the "Pick Color" button, a crosshair appears. Before you are clicking anywhere to select the color, you can wait as long as you want :) If I did not understand you correctly, please clarify.
it grabs the server - try to activate another window after activating the picker (not to mention to "hover" sth.) - so you can wait, but not really change anything
*** This bug has been marked as a duplicate of bug 172921 ***