Created attachment 148984 [details] Observed result STEPS TO REPRODUCE 1. Open Krita and create a new file 2. Open "Specific Color Selector" from Settings -> Dockers -> Specific Color Selector OBSERVED RESULT The RGB sliders are blank. EXPECTED RESULT The RGB sliders should show the grandient colors (https://docs.krita.org/en/reference_manual/dockers/specific_color_selector.html) SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Created attachment 150398 [details] Black color in the the color sliders with Qt 5.15
I built Krita from latest master, 76a9e434dd, and as this bug explains the sliders from Specific Color Selector docker in my case they only show the black no matter how you move the slider. I suspect that his bug it's due to Qt 5.15, I'll use the version from KDE's git, and even tried to apply Krita patches, most of them are already applied on Qt from KDE git, but still the sliders don't update the color, and they remain in black. With the Krita appimage from Krita Next which uses Qt 5.12 this docker works as expected.
Yes, this probably is because of a change in Qt itself. If I run an old pre-5.0 build after updating my linux installation to the latest Qt, the sliders are black. And back when I made that old build, more than a year ago, the sliders worked...
Oh, and the last meaningful change to KoColorSlider was in 2016.
It's a problem with the Breeze style apparently, because the sliders are coloured properly when using the Fusion style or the Windows style. This is with Arch qt5-base=5.15.5+kde+r163-1, breeze=5.25.1-1.
Ah, good point. Let's move to breeze then.
Git commit c65b9e93e57651cd119ef759fee2e8ecfb0c3c43 by Halla Rempt. Committed on 05/07/2022 at 11:08. Pushed by rempt into branch 'master'. Disable Breeze until the slider regression is fixed M +1 -1 libs/ui/KisApplication.cpp https://invent.kde.org/graphics/krita/commit/c65b9e93e57651cd119ef759fee2e8ecfb0c3c43
Git commit 3672c200b1a19b6ae831c2335746d4b190b79ab2 by Halla Rempt. Committed on 05/07/2022 at 11:09. Pushed by rempt into branch 'krita/5.1'. Disable Breeze until the slider regression is fixed (cherry picked from commit c65b9e93e57651cd119ef759fee2e8ecfb0c3c43) M +1 -1 libs/ui/KisApplication.cpp https://invent.kde.org/graphics/krita/commit/3672c200b1a19b6ae831c2335746d4b190b79ab2
That's a disappointing approach. You'd be frustrated if Plasma devs masked krita from our menus on immediate receipt of a bug report.
I'm really sorry about that, but this problem makes that part of Krita unusable; a bug in Krita doesn't make plasma unusable. And we're at most a couple of weeks away from a new major release.
(In reply to David Edmundson from comment #9) > That's a disappointing approach. You'd be frustrated if Plasma devs masked > krita from our menus on immediate receipt of a bug report. I don't think they are comparable situations, what Halla did was just to prevent user's frustration, and not to discredit any KDE developer. I'm sure she will restore Breeze style support when this bug will be fixed. To be fair, I prefer to use Krita with the Breeze style and even I built Krita myself to have better KDE integration, but this bug hits my workflow. In the meanwhile, I prefer to user Krita with the Fusion style until this bug is fixed.
Reproducible with kgradientselector (which has the same abstract base within frameworks) if and only if KSelector::setIndent is true It isn't that it doesn't show a colour, but it appears to be painting the background on top on the contents. The breeze commit that surfaced the bug is: commit f6ef4f4738a5d3b6a07b7b11451af19635c8acd9 Author: Jan Blackquill <uhhadd@gmail.com> Date: Wed May 12 18:21:24 2021 -0400 Draw background for frames kstyle/breezestyle.cpp | 2 +- 1 file changed, 1 insertion(+), 1 ----- KSelector is doing: 0115 drawContents(&painter); 0131 style()->drawPrimitive(QStyle::PE_Frame, &opt, &painter, this); Which explains the drawing on top. I would argue strongly that's a client side bug not a breeze one. Swapping this around should fix it. So would explicitly setting the background colour to transparent.
So it's a bug in kselector?
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kwidgetsaddons/-/merge_requests/139
Git commit 565394c7f694b8b79133845ac98d5e928d4cd384 by Christoph Cullmann, on behalf of David Edmundson. Committed on 17/08/2022 at 21:45. Pushed by cullmann into branch 'master'. Paint frame before contents KSelector has custom contents combined wtih a frame from the style. Styles may choose to paint an opaque background. For that reason it's important to paint the frame before the contents. This brings us in line with other Qt widgets that use frames. M +5 -5 src/kselector.cpp https://invent.kde.org/frameworks/kwidgetsaddons/commit/565394c7f694b8b79133845ac98d5e928d4cd384
Git commit d253418be79f8baec070e52573b172d0ffe825a9 by Halla Rempt. Committed on 18/08/2022 at 07:00. Pushed by rempt into branch 'krita/5.1'. Re-enable breeze M +1 -1 libs/ui/KisApplication.cpp https://invent.kde.org/graphics/krita/commit/d253418be79f8baec070e52573b172d0ffe825a9
Thank you! It's a pleasure to use back the Breeze style with Krita.