Discussion:
[plasmashell] [Bug 401644] New: Certain Plasmoid textual elements have poor legibility when used with transparent themes
Add Reply
Filip F.
2018-12-02 10:05:31 UTC
Reply
Permalink
https://bugs.kde.org/show_bug.cgi?id=401644

Bug ID: 401644
Summary: Certain Plasmoid textual elements have poor legibility
when used with transparent themes
Product: plasmashell
Version: master
Platform: Other
OS: Linux
Status: REPORTED
Severity: minor
Priority: NOR
Component: general
Assignee: ***@davidedmundson.co.uk
Reporter: ***@gmail.com
CC: plasma-***@kde.org
Target Milestone: 1.0

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: Loading Image...

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:
Loading Image...

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.
--
You are receiving this mail because:
You are watching all bug changes.
David Edmundson
2018-12-04 17:38:01 UTC
Reply
Permalink
https://bugs.kde.org/show_bug.cgi?id=401644

David Edmundson <***@davidedmundson.co.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
Flags| |VisualDesign+
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.
--
You are receiving this mail because:
You are watching all bug changes.
Filip F.
2018-12-04 18:41:07 UTC
Reply
Permalink
https://bugs.kde.org/show_bug.cgi?id=401644

--- Comment #2 from Filip F. <***@gmail.com> ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
Nate Graham
2018-12-07 00:45:39 UTC
Reply
Permalink
https://bugs.kde.org/show_bug.cgi?id=401644

Nate Graham <***@kde.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@kde.org
Ever confirmed|0 |1
Status|REPORTED |CONFIRMED

--- Comment #3 from Nate Graham <***@kde.org> ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
Filip F.
2018-12-07 14:50:02 UTC
Reply
Permalink
https://bugs.kde.org/show_bug.cgi?id=401644

--- Comment #4 from Filip F. <***@gmail.com> ---
(In reply to Nate Graham from comment #3)
Post by Nate Graham
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?
--
You are receiving this mail because:
You are watching all bug changes.
David Edmundson
2018-12-07 16:46:36 UTC
Reply
Permalink
https://bugs.kde.org/show_bug.cgi?id=401644
Post by Filip F.
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.
--
You are receiving this mail because:
You are watching all bug changes.
Filip F.
2018-12-07 18:03:25 UTC
Reply
Permalink
https://bugs.kde.org/show_bug.cgi?id=401644

--- Comment #6 from Filip F. <***@gmail.com> ---
(In reply to David Edmundson from comment #5)
Post by David Edmundson
Post by Filip F.
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:
Loading Image...

If we open KickoffItem.qml and at line 144 comment out "opacity: isCurrent ?
0.8 : 0.6" we get white text back:
Loading Image...

We can also try to hardcode a color, such as Breeze Dark's inactive text color
(#bdc3c7): Loading Image...

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 :/
--
You are receiving this mail because:
You are watching all bug changes.
David Edmundson
2018-12-07 18:30:46 UTC
Reply
Permalink
https://bugs.kde.org/show_bug.cgi?id=401644

--- Comment #7 from David Edmundson <***@davidedmundson.co.uk> ---
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
--
You are receiving this mail because:
You are watching all bug changes.
Filip F.
2018-12-07 18:40:07 UTC
Reply
Permalink
https://bugs.kde.org/show_bug.cgi?id=401644

--- Comment #8 from Filip F. <***@gmail.com> ---
(In reply to David Edmundson from comment #7)
Post by David Edmundson
https://bugreports.qt.io/browse/QTBUG-70138
one more (stupid) thing to try, just to determine something
+ 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:
Loading Image...

I double checked by setting the variable to NativeRendering and that
additionally confirmed the finding.
--
You are receiving this mail because:
You are watching all bug changes.
Loading...