Summary: | Certain Plasmoid textual elements have poor legibility when used with transparent themes | ||
---|---|---|---|
Product: | [Plasma] plasmashell | Reporter: | Filip Fila <filipfila.kde> |
Component: | general | Assignee: | David Edmundson <kde> |
Status: | RESOLVED UPSTREAM | ||
Severity: | minor | CC: | nate, plasma-bugs |
Priority: | NOR | Flags: | kde:
VisualDesign+
|
Version: | master | ||
Target Milestone: | 1.0 | ||
Platform: | Other | ||
OS: | Linux | ||
URL: | https://bugreports.qt.io/browse/QTBUG-70138 | ||
Latest Commit: | Version Fixed In: |
Description
Filip Fila
2018-12-02 10:05:31 UTC
>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? |