SUMMARY Currently using fairly transparent themes can be troublesome because some plasmoid textual elements have poor legibility. The problem is present in pretty much all of the plasmoids. As exemplified in the case of Kickoff's menu item subtitles, the code sets the opacity at 60% when inactive and 80% when active, which is the cause of the legibility problems. IMO a better solution would be e.g. to call upon the "inactive text" class color (although this value in Breeze would need adjusting, Breeze Dark is fine). OBSERVED RESULT See screenshot: https://i.redd.it/4np7y2i3w4021.png Some plasmoids' text when using transparent's themes is not legible when the plasmoid is superimposed over a lighter background. EXPECTED RESULT See screenshot when calling upon inactive text color of Breeze Dark: https://i.ibb.co/Wsd5RvC/Screenshot-20181202-105714.png Text is legible. ADDITIONAL INFORMATION I would be thrilled to do work related to this myself and implement any kind of suggestions from more experienced people, but I'd need to know if it would be up for consideration when reviewed.
>but I'd need to know if it would be up for consideration when reviewed. Depends. There's a questionable bit of code that in order to make subtexts grey with either black or white themes by altering it's opacity. *If* that's the cause, I'd be happy to fix that in another way. (Note, that also ties in with a bug in QtQuick text handling of opacity that I fixed only in Qt5.12) If it's simply that grey isn't viewable on a greyish background, then there's not much we can do. I would reject a patch adding countless glows and shadows to combat a user choosing settings that simply don't work.
Thanks for looking into this David! Yes, I've now have had a look at some of the affected Plasmoids such as Kickoff, Media Controller, Network Monitor, Battery & Brightness. In all of them grey subtitle text is achieved by lowering the opacity of the default text color (white or black). Usually the value is 60% opacity. Since this method is used so consistently perhaps there was a reasoning behind it. Maybe the tagged VDG members would know? > I would reject a patch adding countless glows and shadows to combat a user choosing settings that simply don't work. I couldn't agree more, that would look awful anyway.
Yeah, I think the specific issue here is caused by using opacity to reduce the intensity of a color in such a manner that lazily makes it work with all color themes--provided there's no significant transparency! However I think it's also up to themes to do their part to ensure adequate contrast. It's well known that contrast falls as background transparency is increased. This doesn't go away simply by blurring it more, because the colors that are being blurred could simple be a bad choice of background for whatever is on the foreground. It's important that the blurred transparent background be lightened (for light themes) or darkened (for dark themes), as with the current login screen. This is what macOS does for transparent elements to ensure contrast.
(In reply to Nate Graham from comment #3) > Yeah, I think the specific issue here is caused by using opacity to reduce > the intensity of a color in such a manner that lazily makes it work with all > color themes--provided there's no significant transparency! > > However I think it's also up to themes to do their part to ensure adequate > contrast. It's well known that contrast falls as background transparency is > increased. This doesn't go away simply by blurring it more, because the > colors that are being blurred could simple be a bad choice of background for > whatever is on the foreground. It's important that the blurred transparent > background be lightened (for light themes) or darkened (for dark themes), as > with the current login screen. This is what macOS does for transparent > elements to ensure contrast. Is it technically possible for a desktop theme to go: "okay, I'm drawing plasmoids over a dark background, I will keep my default 60% opacity" and then conversely "I notice I'm drawing over a light background, I will increase the opacity of the affected plasmoids to compensate"? Example scenario for the latter would be the user working in Kate and then opening Kickoff, which is drawn above Kate's white background, resulting in legibility issues. Seems like having this sort of opacity modularity in the theme would be the only solution that themes could implement?
>Is it technically possible for a desktop theme to go Not really. -- Lets test first if it is caused by this opacity shenanigans before we jump to any solutions. Filip, just find one of the bits of code and hardcode an opacity and colour override.
(In reply to David Edmundson from comment #5) > >Is it technically possible for a desktop theme to go > > Not really. > > -- > > > Lets test first if it is caused by this opacity shenanigans before we jump > to any solutions. Filip, just find one of the bits of code and hardcode an > opacity and colour override. Okay, so let's test it with the Breeze Transparent Dark theme and Kickoff application subtitles. This is what Kickoff looks like when superimposed over Kate: https://i.ibb.co/7NbQzH1/Screenshot-20181207-185057.png If we open KickoffItem.qml and at line 144 comment out "opacity: isCurrent ? 0.8 : 0.6" we get white text back: https://i.ibb.co/tBYMVpx/Screenshot-20181207-185132.png We can also try to hardcode a color, such as Breeze Dark's inactive text color (#bdc3c7): https://i.ibb.co/S5CVnfh/Screenshot-20181207-185238.png But in my tests I've found that calling upon the inactive text color of color schemes would not look the best with some schemes. So far I've had moderate success with this piece of color code I took from Nate's separators patch: isCurrent ? Qt.tint(PlasmaCore.ColorScope.textColor, Qt.rgba(PlasmaCore.ColorScope.backgroundColor.r, PlasmaCore.ColorScope.backgroundColor.g, PlasmaCore.ColorScope.backgroundColor.b, 0.1)) : Qt.tint(PlasmaCore.ColorScope.textColor, Qt.rgba(PlasmaCore.ColorScope.backgroundColor.r, PlasmaCore.ColorScope.backgroundColor.g, PlasmaCore.ColorScope.backgroundColor.b, 0.2)) It fixes transparent themes, Breeze remains looking the same, however Breeze dark has lighter subtitles than before :/
Oh, I never submitted a patch for: https://bugreports.qt.io/browse/QTBUG-70138 one more (stupid) thing to try, just to determine something in the Label please set: + renderType: Text.QtRendering
(In reply to David Edmundson from comment #7) > Oh, I never submitted a patch for: > https://bugreports.qt.io/browse/QTBUG-70138 > > one more (stupid) thing to try, just to determine something > > in the Label please set: > + renderType: Text.QtRendering Definitely not a stupid thing to try since that bug actually seems to be the cause of the problems! Switching to QtRendering results in: https://i.ibb.co/mSZyBsq/Screenshot-20181207-193424.png I double checked by setting the variable to NativeRendering and that additionally confirmed the finding.
Should I mark this as an upstream bug then?