Created attachment 139473 [details] Screenshot of krunner without text entered. krunner text input field uses white as background color, regardless of desktop color scheme setting. But it also uses the color scheme's foreground color for text entered into the same field, yielding (in my case) a very bright grey text on a white background, which is absolutely unreadable. Marking the entered text is the only way to produce enough contrast. STEPS TO REPRODUCE 1. Select a dark color desktop theme, f.ex. "Obsidian Coast" or "Breeze Dark" 2. Show krunner widget 3. Enter some text. OBSERVED RESULT The "search" hint remains lightly visible, as it uses a darker gray, but once I start typing, the text is displayed in such a bright color it is barely visible if at all. EXPECTED RESULT krunner's text input field should either use a dark background color (i.e. the same as f.ex. the search bar in systemsettings) or a darker foreground text color, so entered text remains readable. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Gentoo Linux (available in About System) KDE Plasma Version: 5.22.1 KDE Frameworks Version: 5.83.0 Qt Version: 5.15.2
Created attachment 139474 [details] Screenshot of krunner with "urxvt" entered as text.
Created attachment 139475 [details] Screenshot of krunner with "urxvt" entered as text and marked for visibility.
Created attachment 139476 [details] Screenshot of krunner without text entered. For comparison, this is how krunner looks like on a bright desktop color scheme ("Breeze") with no text entered.
Created attachment 139477 [details] Screenshot of krunner with "urxvt" entered as text. For comparison, this is what krunner looks like with "urxvt" entered on a bright desktop scheme ("Breeze").
Created attachment 139491 [details] Krunner input field with Materia Dark Can you check with other themes? Because for me Krunner is applying the color schemes properly, and I checked with Materia-Dark, Breeze-Dark. Attached screenshot is with Materia-Dark.
For what it's worth, it seems Krunner (along with the lockscreen, btw) seems to use only the global design settings. In my case, I use "Oxygen", which is, by default, a bright design scheme and then I select another, dark color scheme (Obsidian Coast). There is no dark variant of oxygen available. When I switch to a default-dark design, f.ex. Breeze-dark, the text colors of both krunner and the lock screen are correct. Interestingly, this showed up only recently. in older Plasma/KF-5 versions, the color scheme was used more properly.
After changing the global design settings it also seems the Oxygen design is no longer fully supported by plasmashell, because to revert to my Oxygen setup I had to recover the full .config/plasma* files from backup, just changing the design did not do the trick anymore.
@Nate, could this be relate to the PC3 port of the QML elements?
That's what it seems, yeah.
In the old PC2 version (plasmastyle/TextFieldStyle.qml), we had this: textColor: control.enabled ? PlasmaCore.Theme.viewTextColor : Qt.rgba(PlasmaCore.Theme.viewTextColor.r, PlasmaCore.Theme.viewTextColor.g, PlasmaCore.Theme.viewTextColor.b, 0.6) selectionColor: PlasmaCore.Theme.highlightColor selectedTextColor: PlasmaCore.Theme.viewHighlightedTextColor placeholderTextColor: Qt.rgba(PlasmaCore.Theme.viewTextColor.r, PlasmaCore.Theme.viewTextColor.g, PlasmaCore.Theme.viewTextColor.b, 0.5) In the new PC3 version (plasmacomponents3/TextField.qml )we have this: PlasmaCore.ColorScope.colorGroup: PlasmaCore.Theme.ViewColorGroup color: PlasmaCore.Theme.textColor placeholderTextColor: PlasmaCore.Theme.disabledTextColor selectionColor: PlasmaCore.Theme.highlightColor selectedTextColor: PlasmaCore.Theme.highlightedTextColor So both are attempting to use the view color group's text color, rather than the window color group's text color. However only the PC2 version is succeeding at it. Ensuring that `PlasmaCore.ColorScope.inherit: false` is set in the PC3 version does not have any effect, so I don't think it's an accidental inheritance issue.
I think I found it. In /home/nate/kde/src/plasma-framework/src/plasma/private/theme_p.cpp, there's this: elements[QStringLiteral("%textcolor")] = color(status == Svg::Status::Selected ? Theme::HighlightedTextColor : Theme::TextColor, Theme::NormalColorGroup).name(); So it always uses the normal color group and does not respect the active color group, boo.
It would be trivial to simply use viewTextColor and remove the colorgroup stuff, but it seems like we should fix the colorgroup stuff not working properly here. I notice that PC3 TextArea is using viewTextColor rather than textColor with the view color group set, so it's working simply because it uses the old PC2-style code. Once the bug is fixed, we should port that over too.
At this point I think I need input from Marco or Niccolò or another Plasma theming expert to proceed.
*** Bug 436276 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/308
(In reply to Bug Janitor Service from comment #15) > A possibly relevant merge request was started @ > https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/308 I can confirm this patch applies cleanly to plasma-5.84 on Gentoo (unstable) and solves the issue with Oxygen theme and dark desktop colors.
Can also confirm
Git commit 435df1385be65e4be78e73bf97792b5084e25cef by Nate Graham. Committed on 05/08/2021 at 22:59. Pushed by ngraham into branch 'master'. [PC3/TextField] Fix text color with certain themes Some themes like Oxygen use opposite colors for their view vs window colors, and the TextField's code did not reflect this. TextArea worked properly, so this commit just lifts the working code from TextArea and puts it in TextField too. FIXED-IN: 5.85 M +4 -3 src/declarativeimports/plasmacomponents3/TextField.qml https://invent.kde.org/frameworks/plasma-framework/commit/435df1385be65e4be78e73bf97792b5084e25cef
*** Bug 441025 has been marked as a duplicate of this bug. ***
*** Bug 441772 has been marked as a duplicate of this bug. ***
*** Bug 437289 has been marked as a duplicate of this bug. ***