| Summary: | breeze / qt theme colors aren't color managed when profile set with colord | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Adam Fontenot <adam.m.fontenot+kde> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | nate, null |
| Priority: | NOR | ||
| Version First Reported In: | 5.19.90 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| URL: | https://bugreports.qt.io/browse/QTBUG-90535 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | screenshot of the problem | ||
|
Description
Adam Fontenot
2020-10-14 01:00:10 UTC
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. |