Version: (using KDE KDE 3.2.2) Installed from: Debian testing/unstable Packages Was initially reported in bug #80389 but filing a new one as suggested. The problem: If 'apply to non-kde apps' is selected, selected menu entries have black text on black bg (eg, gnucash) This is observed when using .NET style with "pale gray" or "next" color schemes. If it matters, window decoration is "glow".
Maybe a dupe of bug #79464, but I'm not sure.
On Thursday 13 May 2004 19:37, Lubos Lunak wrote: > Maybe a dupe of bug #79464, but I'm not sure. That bug had a problem with determining what's selected and what's not. This bug refers to not being able to even read what's written if a menu item is selected. Can they be the same?
Hi! I think a debian user also just reported this to debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=415810 Text quoted here: When setting "apply colors to non kde apps" in the color dialog of kcontrol, the resulting files .kde/share/config/gtkrc and gtkrc-2.0 do not include the line fg[PRELIGHT] = { X X X } in style "MenuItem" { bg[PRELIGHT] = { X X X } } This is especially annoying when the prelight color of menu items has a dark background because the fg color defaults to black... end-of-quote (kde 3.5.5) /Sune
I do ocassionaly see this in gtk aps, like Firefox and Pidgin but it seems to have been resolved in 4.2
Created attachment 81084 [details] Example of bad colors: Left (kwrite) with correct fg/bg, right (Gimp) with incorrect and unreadable fg Not resolved for me. As of KDE 4.10.4, highlighted menu entries in GTK+ apps still always show black foreground, making color schemes with dark selected background colors unreadable. In fact, it's been broken like this since KDE 3. See attachment for example.
In the gtkrc and gtkrc-2.0 files in ~/<kde-dir>/share/config, I see the following near the top: style "default" { bg[NORMAL] = { 0.824, 0.800, 0.745 } bg[SELECTED] = { 0.490, 0.039, 0.039 } bg[INSENSITIVE] = { 0.824, 0.800, 0.745 } bg[ACTIVE] = { 0.678, 0.659, 0.612 } bg[PRELIGHT] = { 0.824, 0.800, 0.745 } base[NORMAL] = { 0.988, 0.984, 0.969 } base[SELECTED] = { 0.490, 0.039, 0.039 } base[INSENSITIVE] = { 0.824, 0.800, 0.745 } base[ACTIVE] = { 0.490, 0.039, 0.039 } base[PRELIGHT] = { 0.490, 0.039, 0.039 } text[NORMAL] = { 0.000, 0.000, 0.000 } text[SELECTED] = { 1.000, 1.000, 1.000 } text[INSENSITIVE] = { 0.678, 0.659, 0.612 } text[ACTIVE] = { 1.000, 1.000, 1.000 } text[PRELIGHT] = { 1.000, 1.000, 1.000 } fg[NORMAL] = { 0.000, 0.000, 0.000 } fg[SELECTED] = { 1.000, 1.000, 1.000 } fg[INSENSITIVE] = { 0.678, 0.659, 0.612 } fg[ACTIVE] = { 0.000, 0.000, 0.000 } fg[PRELIGHT] = { 0.000, 0.000, 0.000 } } If I change the fg[PRELIGHT] at the end to { 1.000, 1.000, 1.000 }, the selected menu text turns white and is readable. Perhaps it is incorrectly being set to the same as the normal fg color. I tried putting the fg[PRELIGHT] line under the MenuItem style like suggested in Comment #3, but it had no effect for some reason, though it seems to work placed in the "default" style. The fact that I know nothing about how .gtkrc works doesn't help much, either. :-)
Confirmed as a problem for me as well. It seems related to this: https://bugs.kde.org/show_bug.cgi?id=304063 But instead of menus, the problem I have is with a particular non-standard menu for choosing presets in Guitarix. The issue is black on black text. I also experience this problem when changing playback speed or track gain in Audacity. I tested this and confirmed it to be a problem when I use oxygen-gtk or qtCurve, but it is not a problem if I choose most of the other (ugly) GTK-style options. In most GTK programs, oxygen-gtk looks great. I have only seen this in Guitarix and Audacity, although there are a few quirks otherwise. For reference, I am using oxygen-gtk 1.3.4, which is not the latest but includes the fix from that other Guitarix-related bug.
Created attachment 89088 [details] showing bad color match background and text in guitarix with gtk-oxygen This shows the unreadable text for presets in Guitarix
Hi, I'm still having this trouble with guitarix. See https://bugs.kde.org/attachment.cgi?id=89088 I have isolated the problem to being gtk2-engines-oxygen. Significantly, there *used* to be a problem with the menus being readable and that was solved with a patch, see https://bugs.kde.org/show_bug.cgi?id=304063 I *think* the continuing problem with the presets panel could be solved by doing almost the same thing as that other patch, but making it apply to this other context and not just menus. I really hope someone can look at this, it's been outstanding for a long time. I have everything else in my system set for gtk-oxygen.
Oops, I need to clarify. This is NOT exclusive to gtk-oxygen. It also has the issue when I use qtcurve, although maybe that's because somehow qtcurve is using the oxygen stuff whereas all the other gtk2 themes are different. All the other gtk2 themes do not have this problem.
Aaron, can you play a bit with the gtkrc-2.0 file, to check which color combination is wrong? Maybe it helps to use http://kde-look.org/content/show.php/CheckColorRoles?content=90034 and apply the colors also to GTK applications. With this theme, wrong color combinations and hard colors are easy to spot for Qt applications, but maybe it also helps isolating your GTK problem.
(In reply to Christoph Feck from comment #11) > Aaron, can you play a bit with the gtkrc-2.0 file, to check which color > combination is wrong? Maybe it helps to use > http://kde-look.org/content/show.php/CheckColorRoles?content=90034 and apply > the colors also to GTK applications. With this theme, wrong color > combinations and hard colors are easy to spot for Qt applications, but maybe > it also helps isolating your GTK problem. Actually, I tried that color scheme and others. The colors in question never change at all. Nothing I do with colors fixes the issue in Guitarix. The only thing that can make it readable is to use a different gtk widget set.
Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I am closing this bug. Kcontrol has been replaced by System Settings in Plasma. Please give the latest version of that a try, and open a new bug in "systemsettings" if you continue to have an issue. Thank you!