Created attachment 114093 [details] KRunner with Breeze default See attachment. Using the default look-and-feel and colour theme Breeze, I can barely distinguish the 'Search…' text in KRunner. Seems to be nearly-white text on white.
It's because it uses a PlasmaComponents1 text field, which has this known bug. Kicker has the same issue for the same reason https://cgit.kde.org/plasma-workspace.git/tree/lookandfeel/contents/runcommand/RunCommand.qml?id=a4a0d5bfd0dabf6be5651244ebe3459b4a257ce2#n65 The PlasmaComponents3 TextField doesn't have this issue, but we haven't ported everything to use that because it doesn't have support for an inline "clear text" button yet. I need to fix that. I'm filing this bug to track it: Bug 396828
What's the issue with the PlasmaComponents 2 text field? Running tests/components/textfield.qml looks fine.
Its label has the issue described in this bug report. I can reproduce this issue on my Kubuntu 18.04 home machine with 5.12.6, and Øystein can apparently reproduce it with Neon and 5.13.3. Sven Mauch can also reproduce it on Arch with 5.13.3, as described here: https://mauch.me/kdewishlist/
Ack, I misread it as you saying you knew what the bug was. Anwyay, I did some investigation: If you attach gammaray the inline preview is fine. If you find the placeholderTextComponent inner item and set the alpha to 255 it's visible and completely black. Turning off compositing brings the text back So the bug: There's a habbit in plasmastyles of using opacity to choose a lighter colour. It's kinda clever as it works on white and black themes. This isn't just place holder text but also the disabled values of most theme parts. It works fine if you have an opaque backgrounds. Plasma dialogs are practically transparent but with a kwin effect making them grey/white with the background contrast thing. Transparent on transparent does not work effecitve opacity is multiplied into nothing. PC3 will have the same issue. I don't know how to fix in a way that keeps theme compatibility.
Created attachment 114103 [details] Text becomes visible with PC3 Switch out the TextField in RunCommand.qml for the PC3 version. The text becomes visible for me; PC3 does not have the same bug (see attached screenshot) And it is a bug, because if the clever logic is designed to choose a good color when the background may be transparent, it's not appropriate for the TextField's label since the background there won't ever be transparent.
Sure it is a bug, but we control drawing the placeholder text and background on both PC2 and PC3. Porting masks the issue instead of fixing it. (arguably ok as we're going to port anyway..but it's still kinda cheating) PC3 *definitely* does a similar thing with opacity. The only difference is that it's an opacity on the item, rather than opacity on the text colour which PC2 has. I still don't fully get the underlying bug, in theory we are over a solid white background, yet toggling compositing does "fix" it.
I'm not sure why it works, but yeah, the PC3 version doesn't exhibit the bug originally described in this ticket. See my latest attachment to this ticket, and Maybe due to the different theming logic compared to the PC2 version? So I guess we have a few options here: 1. Find and fix the bug in the PlasmaComponents2 theming logic that causes placeholder text to have the wrong color with light themes 2. Port missing features to the PlasmaComponents3 text field and move PC2 text field users to the new-and-improved PC3 version. I submitted a patch for the first half of this: https://phabricator.kde.org/D14345 3. Create a QQC2-based Kirigami text field that deprecates both of them and has all of their features, and move PC2 and PC3 text field users to it (I'm willing to do this if my patch for #2 is rejected) 4. Something else...?
Chased the bug. After many hours of going completely mad...it's not our code. It's a bug in QtQuick ... and only when native rendering is being used. Somehow when opacity is set on the glyph as well as blending the background it sets the opacity on the final texel, even if there's an opaque item behind it. PC3 *is* also broken...but detection of which render type to use is also apparently broken(!) which means it's going into the non-native version for the label and we don't see it.
https://bugreports.qt.io/browse/QTBUG-70138
Wow, nice sleuthing!
Thanks for the hard work.
Git commit 2faa71a55a750d54c941aa6dd73ec02cfc9be34b by David Edmundson. Committed on 28/08/2018 at 09:26. Pushed by davidedmundson into branch 'master'. Workaround bug with native rendering and opacity in TextField text Summary: Problem is identified in https://bugreports.qt.io/browse/QTBUG-70138 with a potential patch for upstream. With native rendering the alpha is pointlessly also set in the glBlendFunc despite also being used in the uniform of the shader. Resulting in a visual bug when used on a window with alpha (such as Dialog) It sucks, but we were starting to see people work round it by copying more invasive workarounds everywhere else which I want to avoid. Test Plan: Looked at a text field Reviewers: #plasma, broulik Reviewed By: #plasma, broulik Subscribers: ngraham, kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D15021 M +5 -1 src/declarativeimports/plasmastyle/TextFieldStyle.qml https://commits.kde.org/plasma-framework/2faa71a55a750d54c941aa6dd73ec02cfc9be34b
*** Bug 399143 has been marked as a duplicate of this bug. ***