SUMMARY Sorry if I didn't get the right product, I guessed. This is actually a pretty serious issue (in my opinion). I've been using the Arc theme colors for months (years?) because I was under the impression that the design folks at KDE hated my eyeballs (sorry). This seems to have been a mistake on my part! The biggest issue is with the "highlight" color, which is a fairly saturated blue. On my monitor it's just *terrible* to look at, it's at best distracting and at worst starts to hurt your eyes. But then today I opened up the config and copied the HTML color (#3daee9) into a web-based color viewer. And it looks fine, it's kind of nice in fact! What seems to be going wrong is that KDE isn't color managing the colors, so they display in the native gamut of my very wide gamut monitor, meaning they're very over saturated. STEPS TO REPRODUCE 1. On a computer with a wide gamut monitor and a calibrated color profile installed: enable the default Breeze theme, and open a program that utilizes the "highlight" color, e.g. Dolphin. 2. Observe the color, and compare to the same color (#3daee9) in a color managed image viewer or web application. OBSERVED RESULT The two colors are very different. EXPECTED RESULT They should be (approximately) the same. I don't think I can emphasize the importance of this enough - all the hard work the visual design team does is almost wasted if the results can't be relied upon to look the same across very different user screens. In my case, I went a very long time just assuming they and I had very different desired aesthetics before I realized this was an issue. One weird thing is that Firefox seems to manage the colors just fine - GTK is set to use the Breeze theme, but the highlight colors (e.g. in the context menu) are not oversaturated. SOFTWARE/OS VERSIONS Linux: Arch Linux 5.9.0-arch1-1 KDE Plasma Version: 5.20.0 (no option for this in the version box yet) KDE Frameworks Version: 5.75.0 Qt Version: 5.15.1
Created attachment 132339 [details] screenshot of the problem This screenshot was taken with Spectacle, tagged with my monitor's color space, then converted to the ProPhoto space, which I have tagged the image with. When opened in a color managed viewer on a monitor with a wide enough color space, it should clearly illustrate the problem I'm talking about. Firefox is on the right, showing #3daee9 in a color managed way. On the left is systemsettings, showing a preview of what this color will look like when applied. (And when actually applied, I can confirm that this is what it looks like.)
Very interesting. I can see the difference in your screenshot, yeah. No idea where to fix this though. Breeze? KWin? Starting with KWin.
are you using night color?
(In reply to Vlad Zahorodnii from comment #3) > are you using night color? No. Anything like that is disabled. Only my screen's profile is enabled in the Color Corrections KCM, and it's working correctly in all color managed applications.
Okay, then it's not a kwin bug.
Where should this bug report go then?
I have no idea to be honest. Maybe somebody else can clarify where this bug report should go. On the OS level, typically, only white point calibration is made. If an application doesn't respect ICC color profiles, then a bug report should be filed against it. As for Qt, I don't think that it allows to apply color profiles to UI elements, e.g. push buttons, labels, etc.
(In reply to Vlad Zahorodnii from comment #7) > As for Qt, I don't think that it allows to apply color profiles to UI > elements, e.g. push buttons, labels, etc. Maybe I've misunderstood, but doesn't that mean this is an issue with Qt? I'm not sure if there's a workaround that KDE can apply, but I'd say "our widget framework can't do color management on UI elements" is a pretty serious problem. (Including because it undermines the work that the VDG does.) To be clear, I *am* referring to the highlight color (and other colors, but that's the important one) that appears on UI elements like radio buttons, checkboxes, and elsewhere. I don't think it would be a reasonable fix to add color management in some of the places this color is used but not others.
In that case, perhaps a Qt bug report would be worthwhile. Can you file one? Thanks!
Finally got around to filing a bug with QT. I'm not familiar with QT from a technical perspective, so I hope I didn't miss anything important. https://bugreports.qt.io/browse/QTBUG-90535 If there's something anyone here can contribute or I made a mistake, feel free to leave a comment over on the QT tracker.