Created attachment 141805 [details] Observed result Accent colors don't look as good with Breeze Dark as they do with Breeze Light. STEPS TO REPRODUCE 1. Look at how accent colors look on "Breeze Light" 2. Change the global theme to "Breeze Dark" 3. Look at how accent colors look on "Breeze Dark" OBSERVED RESULT Accent colors don't look as good in Breeze Dark. EXPECTED RESULT Accent colors should not as good as in Breeze Light. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 34 KDE (available in About System) KDE Plasma Version: 5.22.90 KDE Frameworks Version: 5.86 Qt Version: 5.15.2
Which colors are you using?
Both screenshots are using the first custom color in the list, which I think is pink, not sure. (color blindness...)
Ok, it looks like the dark colors are indeed too dark.
Created attachment 141850 [details] dark color presets
Perhaps we need to provide a different default color set if we detect that a dark color scheme is in use? The KCM already has a heuristic for that, helpfully enough. On the other hand, this would mean that if the user switches to a light color scheme later, the accent color will be too light. And vice versa.
(In reply to Nate Graham from comment #5) > Perhaps we need to provide a different default color set if we detect that a > dark color scheme is in use? The KCM already has a heuristic for that, > helpfully enough. I don't think not detecting the color scheme is the issue here. Light themes don't have super dark accent colors. > On the other hand, this would mean that if the user switches to a light > color scheme later, the accent color will be too light. And vice versa. If the user switches their color scheme, why wouldn't we just recalculate the accent color?
I suppose we could. That would be a bit messy though, and require letting the QStyle know about accent colors, right? Currently it is insulated from the concept.
*** Bug 445882 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #7) > I suppose we could. That would be a bit messy though, and require letting > the QStyle know about accent colors, right? Currently it is insulated from > the concept. No, the QStyle would use the same color roles it already uses.
*** Bug 446849 has been marked as a duplicate of this bug. ***
Also, one thing is that the accent color intensity is not the same in checkboxes and highlighted buttons.
I agree rn accent colors are way too dark in dark mode making certain things quite difficult to see, highlighting text causes them to become hard to see and the sliders for the settings app icon are also quite difficult to see. I am using the purple accent color btw. and its only a bit better on the other accent colors
Reading selected text on Okular is really hard with the way accent colors work under dark color schemes. The ramifications of this issue go on to make the experience on some KDE tools a bit worse.
The dull colour is sort of intentional: it helps to preserve legibility when you have accent foreground on accent background, which is a thing that some apps do. I could increase the accent colour background's brightness, but that might impair legibility in the situation the dullness was designed for.
Created attachment 147112 [details] Default Breeze Dark
Created attachment 147113 [details] Green Breeze Dark
I think the generated colors are fine, but they are being used incorrectly. As an example, see the attached images. With the default Breeze Dark, the Disconnect button is outlined with the lighter version of the color, making it clearly visible. With accent colors (I only created screenshots with the green) the outline is dark green, the same as the background. I think this is what happens in the first attachment (by Felipe Kinoshita), in which the slider uses the dark color and is less legible.
Created attachment 147147 [details] Okular selected text under dark color scheme with accent color enabled Highlighted text is impossible to read under a dark color scheme on Okular when using accent colors. I have to crank up the screen brightness to distinguish what I want to select. Given that this color scheme change may have ramifications pretty much on every application using KDE Frameworks in an unexpected way, is this truly the right way to proceed? Solving on a case by case basis sounds like an impossible task.
*** This bug has been marked as a duplicate of bug 451967 ***
Oops, did it in reverse.
*** Bug 451967 has been marked as a duplicate of this bug. ***
*** Bug 451698 has been marked as a duplicate of this bug. ***
Git commit 6750353c9fda821050ddc0a02e533c857472f287 by Nate Graham, on behalf of Jan Blackquill. Committed on 08/04/2022 at 22:26. Pushed by ngraham into branch 'master'. kcm/colors: don't dull accent colour on dark themes in colorsapplicator User demand shows that bright accent colours are wanted over potentially better legibility, so let's avoid changing them. FIXED-IN: 5.25 M +1 -7 kcms/colors/colorsapplicator.h https://invent.kde.org/plasma/plasma-workspace/commit/6750353c9fda821050ddc0a02e533c857472f287
Is there any chance for the change to be backported for 5.24? I can make a merge request to get the change to the Plasma/5.24 branch if that's the case. User demand seems rather high based on the votes and CC numbers, plus 5.24 is LTS so some people may be stuck with it for a while too if this fix is only for 5.25 onwards. I just applied the patch on top of 5.24.4 on my system and it makes my use case of using Breeze Dark but with the libadwaita accent colour work much better (previously I had to take the original accent colour and crank the V component of the HSV values up to 255, and even then it was still too dark in some places), and I don't see any contrast issues either as a result.
Yes, it's a harmless and trivial change, easily and safely backportable. The reason why I didn't do it already is because in the interest of keeping the UI stable across a single release, the Plasma backport policy is that we only backport bugfixes, not intentional UI changes. If y'all can convince me that this change is more of a bugfix than an intentional UI change, I'll happily backport it. :) So sharpen those debate skills and make some convincing cases!
This patch doesn't change the behavior of light themes. The selection background still doesn't match the accent colour in light or dark themes. The patch makes it slightly closer in dark themes only.
(In reply to Nate Graham from comment #25) > If y'all can convince me that this change is more of a bugfix than an > intentional UI change, I'll happily backport it. :) So sharpen those debate > skills and make some convincing cases! I don't really know if you had the time to check the attached file I uploaded in this very bug report, named "Okular selected text under dark color scheme with accent color enabled". In my opinion, it shows that not backporting this behavior will make KDE apps like Okular stop doing their job properly in hard to tackle ways; I still am not able to reliably select text using a dark color scheme up until this behavior gets fixed in my distro. Should this behavior not be backported by the time Kubuntu 22.04 releases, I expect some users to be... confused by not being able to read the text they select in an app as important as that one is (and don't even get me started in other less used applications!). I think not fixing this behavior everywhere is jeopardizing just for the sake of it. Sorry if my language is a bit too strong, I just recommended Kubuntu to a friend and I wouldn't like his experience to be disturbed by things like this one.
Now that I think about it, this is clearly a bugfix since we were inappropriately double-tinting the color. The change to fix this still has a single tint, which is currently intentional, and tracked by Bug 451698. I'll backport it.
Git commit edf4b01cfad748441a31c8358866a3aa0ce36d6b by Nate Graham, on behalf of Jan Blackquill. Committed on 09/04/2022 at 17:08. Pushed by ngraham into branch 'Plasma/5.24'. kcm/colors: don't dull accent colour on dark themes in colorsapplicator User demand shows that bright accent colours are wanted over potentially better legibility, so let's avoid changing them. FIXED-IN: 5.25 (cherry picked from commit 6750353c9fda821050ddc0a02e533c857472f287) M +1 -7 kcms/colors/colorsapplicator.h https://invent.kde.org/plasma/plasma-workspace/commit/edf4b01cfad748441a31c8358866a3aa0ce36d6b