Created attachment 147602 [details] Screenshot showing accent colors lightening Dolphin's folder icon and darkening menu background SUMMARY On Breeze Light/Classic color schemes, if I pick an accent color, then hover a Qt Widgets menu item, the background is *darker* than the accent color (making black text unreadable), rather than lighter with accent color off. STEPS TO REPRODUCE 1. Open System Settings to Colors, and pick Breeze Light or Classic. 2. Pick any accent color, and click Apply. 3. Open Konsole. (You can also open it before changing accent colors. Other apps like KWrite or Dolphin work too.) 4. In Konsole, hover a menu item. OBSERVED RESULT The menu item has a dark colored background behind black text. EXPECTED RESULT The menu item has a light colored background behind black text. SOFTWARE/OS VERSIONS Operating System: Arch Linux ARM KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 Kernel Version: 5.17.0-rc7-asahi-next-20220310-5-1-ARCH (64-bit) Graphics Platform: X11 Processors: 4 × Apple M1 Firestorm, 4 × Apple M1 Icestorm Memory: 7.4 GiB of RAM Graphics Processor: llvmpipe ADDITIONAL INFORMATION The bug also happens on x86 hardware. Additionally I feel *all* of the accent colors are too light, making light text harder to read compared to turning off accent color and using Breeze's default selection blue. Picking a custom darker accent color to make light text easier to read makes dark text even harder to read, due to this bug.
Yeah, the actual colors that get written to the color scheme are changed a bit, which causes issues like this. See also Bug 442820.
*** This bug has been marked as a duplicate of bug 442820 ***
Bug 442820 is "fixed" by https://invent.kde.org/plasma/plasma-workspace/commit/6750353c9fda821050ddc0a02e533c857472f287. I cherry-picked it on plasma-workspace 5.24, rebuilt, and *this* bug is still not fixed (using the blue accent color, Dolphin's icon is too light and the menubar is too dark). That's because the commit changes dark themes to act like light themes, but my bug occurred on a light theme to begin with, and is still happening.
*** Bug 451967 has been marked as a duplicate of this bug. ***
I did some investigation here and discovered the following: 1. We currently blend the accent color 70/30 with the color scheme's background color 2. This is done at the moment of application, so the color you choose is not exactly the color you get; the final color depends on the base color scheme. It also means that if you change the base color scheme, your accent color changes too 3. We do this for two reasons: 3a. to make the accent color visually fit in with the parent color scheme better 3b. to prevent any color in the color scheme that would otherwise be identical to the accent color (e.g. the link color) from disappearing when it's a part of a list item that gets selected We could resolve 3b in a different way, by changing the link color rather than the applied accent color. However for 3a, we would have to throw that out completely, as it is not compatible with the idea of using the exact accent color that you choose without processing it at all. As a result, any accent color you set that looks good on a light theme might seem too bright on a dark theme, and any accent color you set that looks good with a dark theme might seem too muted on a light theme. I don't see a good way of preventing that unless we keep the current behavior. Thoughts?
Created attachment 148112 [details] Barely visible dimmed accent color even with a bright original accent color
I get the idea behind 3a, but I think that the way it is currently done, it does more harm than good. Look at the attached screenshot for example; this is a tint of pink with the brightness slider set to the highest brightness value possible, and notice how even with the very light original accent color as seen in the tab indicator, the volume sliders are barely even visible at all. This is really not good. And for most other basic colors as well, I have not managed to manually find a corresponding accent color that is good-looking or even well-readable with Breeze Dark. In contrast, when I pulled from the original accent color for a window decoration (https://store.kde.org/p/1709569) and an icon set (https://github.com/vinceliuice/Tela-icon-theme/issues/175#issuecomment-1019377238) and used it with a dark color scheme, I did not find it too bright at all, and much better than the dimmed version, and conversely also found the watered down version when using the selection color on light icon schemes a little too pale compared to the original accent color. Both as seen in the Breeze rainbow folders and the upcoming titlebar/header rainbow colors. In addition, even if one were to try and tweak the current numbers in one or the other direction, I think that Plasma trying to outsmart the user in the choice of the accent color only leads to confusion; a few days ago on KReddit I read a comment saying the current behavior must clearly be a bug as the applied accent color did not match the selected one. So my amateur conclusion is that leaving the chosen accent color alone or at least not dimming it as extremely, and letting the user choose an accent color that works well for their background, leads to better results than unconditionally changing values in an attempt to automatically perfect every color scheme possible.
Simply blending two colours together like this does not actually guarantee that the result "fits". If I want an accent colour that is similar to one of the colours in my base theme, I can just pick that colour in the colour picker. Also, reiterate that I don't think the accent should affect link colour at all. I have also noticed KDE blending together colours from the advanced palette, even if you don't use accents, eg the selected background and unselected background are blended to make the hover background. I would really like to get rid of all those hover effects. I don't know if that is possible, but making the hover colour = the unselected colour is not an option due to this.
> In addition, even if one were to try and tweak the current numbers in one or the other direction, > I think that Plasma trying to outsmart the user in the choice of the accent color only leads to confusion Indeed, this seems quite apparent. > Also, reiterate that I don't think the accent should affect link colour at all. Yes, that's another possible solution for the issue of links in selected items disappearing. I'll experiment with that.
Chiming in as I think this is what I've just noticed when testing latest daily build of openSUSE Krypton. "Use accent color" results in different appearance between "From current color scheme" and "Custom", despite providing the same colour value. I am not familiar with the color scheme or accent feature. Playing around with editing a color scheme, it seemed the "Selection Color" was mapped to the accent used by the scheme, and the contrast slider in the options tab made no difference. I liked the brighter accent from the scheme, but when text was involved (white text in a dark theme), the text was not readable. I was hoping the contrast slider would have helped with that. When using "Custom" for accent source instead, the dimmed accent was much better for readability (file selected in Dolphin). --- I also noticed in the systray "Audio Volume" applet that the tabs used the color scheme "Hover Decoration". That colour change would not be visible until I changed back to "Custom" accent, applied, and back to "From current color scheme", or by changing the "Selection" colour in the scheme also would update the colour used in the applet tab.. I guess it relied on the accent colour being adjusted as other settings did not seem to make a difference at updating the visual. When "Custom" is used for the accent, it would override the "Hover Decoration" from the colour scheme, it seems to be the colour value assigned to "Custom" without any alterations, while the applets sliders beneath the "Devices" tab have the dulled accent (testing with a bright red). I guess "Custom" accent overrides multiple colors from the scheme this way? Or the other way around, and the "From current color scheme" replaces the accent with a variety of sources? As a user who's not strayed from the defaults before, it's unclear to me what is overriding the other, and what values in a color scheme map to the accents "Custom" affects. --- While the accent adjustments for contrast with "Custom" seem to be otherwise good for readability, I get the impression there is a consistency issue. Not only is the "Selection" colour used from the scheme as an accent, with "Custom" adjusting the value, "Custom" is also applying the accent chosen on other colours from the scheme that were a different colour. It's a very different experience between the two for me. My expectation was that "Use accent color" selects a source for the accent, not to modify it or override other colours from the scheme too. That sounds like a different setting that provides dynamic contrast (nice), and overrides (vague, possibly some visual/contextual hierarchy?)