Bug 355540

I can confirm that on update Arch Linux, however there is something more. I fo you do:
find ~ -name "*gtkrc*"
remove all found content and reconfigure gtk theme in kde systemsettings (choosing breeze of course), then things are getting back to normal for a session time. Both in inkscape and gimp tooltips consist of white letters on black background. After relogin tooltips are not readable again, as shown is previous post.

*** Bug 355879 has been marked as a duplicate of this bug. ***

Same problem for me, see also my screenshots in https://bugs.kde.org/show_bug.cgi?id=355879 (closed as duplicate)

Same problem, and I found that by removing this line:

"""widget "gtk-tooltip" style "ToolTip"

in ~/.config/gtkrc-2.0,  tooltip colors back to normal.

I experience the same issue GTK+2 and GTK+3 have light on light tooltip.

But additionally I can see in a PyQt4 app (PyQt5 works), that the tooltip is not like the default Breeze color scheme, it shows dark text on a light background.

So it seems that only Qt5 apps use the Breeze color scheme style.

Arch Linux
Plasma 5.5.2
KF 5.17
Qt 5.5.1
GTK+ 3.18.6

Qt4 and Qt5 tooltips
http://i.imgur.com/xr5bQtX.png

as written in in gtkrc-2.0:
# If you do not want KDE to override your GTK settings, select
# Appearance -> Colors in the System Settings and disable the checkbox
# "Apply colors to non-KDE4 applications"

after then my gtkrc-2.0 only contains: "gtk-alternative-button-order = 1"

solved it for me for gimp and inkscape: white text in black background, when I use breeze for gtk-apps

Given we haven't found any way to solve this (as we're using pixmap rather than a custom engine like Oxygen), should we automatically switch the 'Apply colors to non-Qt applications' off when Breeze-GTK is selected? That may be fairly complicated, but I'm not certain of any alternative since pixmap isn't actively maintained.

I don't know anything about the technical context and what 'Apply colors to non-Qt applications' really does.
I did not know pixmaps is part of these contexts.

If I understand it right, it's gimp/inkscape, who do not understand or ignore the color codes set by KDE in /.config/gtkrc-2.0
yes, then disabling it by default would be a good workaround

There are still some themes (Oxygen, Bespin, QtCurve) that appear to utilize the functionality, so we should only 'turn it off' for Breeze, I think, if it's possible to do so. If we get around to recreating the theme-generation script that pre-applies the colors, I would prefer to have that checkbox activate the script rather than whatever it's trying to do now.

Still, that's a chunk of work outside of the theme itself. That's a long ways out, as I'm not certain I'll be able to contribute to the theme for a while.

I just noticed the same problem while trying to run Dia. I'm beginning to wonder if it might be a bad idea overall to try to apply Plasma/KDE/Qt themes to GTK apps, and if it wouldn't be preferable to let GTK apps be styled separately, which is I think what a lot of non-KDE platforms end up implementing for Qt apps. It shouldn't be our job or our place to muck with the HIG of non-native platforms, at least, not by default certainly.

(In reply to ipatrol6010 from comment #11)
> I just noticed the same problem while trying to run Dia. I'm beginning to
> wonder if it might be a bad idea overall to try to apply Plasma/KDE/Qt
> themes to GTK apps, and if it wouldn't be preferable to let GTK apps be
> styled separately, which is I think what a lot of non-KDE platforms end up
> implementing for Qt apps. It shouldn't be our job or our place to muck with
> the HIG of non-native platforms, at least, not by default certainly.

The problem is KDE-GNOME and Qt-GTK are going far away from each other in look and feel. All desktop environment want to give users same experience on all applications. That is way they enable breeze style on GTK apps. The real problem is that the Breeze theme for GTK is not fully tested as Oxygen.

By the way, why this is still unconfirmed though so many people have the same problem?

I feel like the ideal solution would be to whitelist Oxygen and any other GTK themes that actually support KDE color schemes and ignore the rest when the 'Apply colors to non-Qt applications' option is checked. Then, when the Breeze theme generation script is mainlined possibly have that activated instead when Breeze is selected.

Whether that is easily detectable/implementable is another matter. Still, it's clear that with our approach to color themes in GTK going forward, the current approach won't work as intended.

In the meantime, you should untick that checkbox if you're using Breeze. That may be why 'unconfirmed' makes sense since this isn't necessarily a bug in the theme itself, but relates more closely to the Color KCM.

(In reply to scionicspectre from comment #13)
> I feel like the ideal solution would be to whitelist Oxygen and any other
> GTK themes that actually support KDE color schemes and ignore the rest when
> the 'Apply colors to non-Qt applications' option is checked. Then, when the
> Breeze theme generation script is mainlined possibly have that activated
> instead when Breeze is selected.
> 
> Whether that is easily detectable/implementable is another matter. Still,
> it's clear that with our approach to color themes in GTK going forward, the
> current approach won't work as intended.
> 
> In the meantime, you should untick that checkbox if you're using Breeze.
> That may be why 'unconfirmed' makes sense since this isn't necessarily a bug
> in the theme itself, but relates more closely to the Color KCM.

Your solution is good. But I still doult if here are some improvements can be done in Breeze GTK theme itself.

> Your solution is good. But I still doult if here are some improvements can
> be done in Breeze GTK theme itself.

This is the best we can do with the recent changes to GTK 3, which is why Oxygen is effectively dead on GTK 3. There are surely improvements to be made to Breeze-GTK itself, but when it comes to color themes in particular, the implementation over on github is as sound as anything I can think of. The only other way to improve this situation is by modifying GTK itself since we can't go back to the way things were. :\

There's a big ugly comment thread in the bug related to the deprecation of the old theming API Hugo was using in Oxygen if you don't want to take my word for it.

(In reply to scionicspectre from comment #13)
> In the meantime, you should untick that checkbox if you're using Breeze.

Excellent! Fixes the problem for me (KDE Frameworks 5.22.0 backports PPA on Kubuntu 16.04). But people shouldn't have to go to the KDE bugbase to have legible tooltips in Gimp, Inkscape, Thunderbird, etc.  This essential workaround should be noted in the KDE/Kubuntu/etc. release notes with something like:

If you're using the default Breeze theme for KDE, and tooltips in non-KDE applications such as Gimp and Thunderbird are difficult to read (white text on gray background), then in System Settings > Color > Options for  the Breeze theme uncheck "Apply colors to non-QT applications" and click [Apply]. (KDE bug 355540)

(This bugbase does not have a "release notes" or "document" tag.)

(In reply to Wulf from comment #7)
> after then my gtkrc-2.0 only contains: "gtk-alternative-button-order = 1"

Even after unchecking "Apply colors to non-QT applications", my $HOME/.kde/share/config/gtkrc-2.0 has a line # created by KDE, Fri Apr 17 00:04:50 2015 and that's the modification date of the file. As well as "gtk-alternative-button-order = 1" it has 50 lines of code, mostly setting a style "default". Should I remove all that styling?

A true fix doesn't lie in extra documentation- the fix is having the KCM ignore the option when any theme with 'Breeze-gtk' in the name is in use. Throwing a suggestion into the release notes would only marginally improve the situation, although it isn't a bad idea. Until the KCM is patched, 'Apply colors to non-QT applications' should be unchecked by default since Breeze-gtk is the default theme.

Since all of these solutions are outside of the scope of what we can accomplish within the theme and GTK, I think this should be reported as a bug for the Colors KCM.

" since Breeze-gtk is the default theme.", that's not necessarily true (depends on your distro).

In fact, last I heard (with my distro-packager hat on), the recommendation from breeze devs was to not use breeze-gtk by default yet, and characterized it's development as ongoing and incomplete.

A workaround that worked for my openSUSE 42.1 (Plasma version 5.6.4):

- Delete ~/.config/gtkrc and ~/.config/gtkrc-2.0
=> GIMP tooltips are readable (white text, dark background)

However, when I restored the two files, the tooltip appearance did not change back. For me this is ok but I thought it is worth noting.

Update: It was only needed to move the "gtkrc-2.0" file away. After restore of the original file I relogged-in and I got the old (wrong) tooltip appearance again.

*** Bug 365937 has been marked as a duplicate of this bug. ***

I can confirm removing:
~/.config/gtkrc
~/.config/gtkrc-2.0

Fixes it in Kubuntu Yakkety Yak with:
Plasma 5.7.2
Frameworks 5.24.0
Qt 5.6.1

I found that using the solution in Comment 4 worked for the session, but reverted with a new session. The same with Comment 22. However

chmod -w ~/.config/gtkrc-2.0

after applying the solution in Comment 4 seems to have fixed it permanently.

openSUSE Leap 42.1
Qt 5.5.1
Plasma 5.5.1
Frameworks 5.21.0

https://bugs.kde.org/show_bug.cgi?id=355540#c7 (System Settings -> (Appearance ->) Colors -> Tab Options -> Disable "Apply colors to non-Qt applications") works for me (openSUSE 42.1, Plasma 5.7.5) and it seems to be a less hacky workaround.

I can confirm on Plasma 5.8. It was working on Gimp, but not on Inkscape.

For me tooltips aren't readable even when I choose Oxygen theme. The background is a little bit darker then (kind of light beige), but still the white text is almost unreadable.

@Paul Sommer: did you really unset "apply colors to non-qt applications"?

When I unset "apply colors to non-qt applications"? everything is fine (white characters on black background).
But Comments 10, 12 and 13 sounds as if it was working correct with the Oxygen theme without that workaround. Did I get this wrong?

I understand that there are numerous workarounds and that it is quite difficult to find the actual issue, but I wonder how this bug can be UNCONFIRMED after so many comments and mentions on the web.
Yes, this bug affects me, too, on the fresh install of openSUSE Leap 42.2.

Created attachment 102762 [details]
Inkscape launched by Dolphin

Created attachment 102765 [details]
Inkscape launched by Kickoff

The bug is present when a file is opened with Inkscape from Dolphin, while everything looks right when Inkscape is launched from Kickoff and a file is selected then. See the attachments.

(In reply to Ilya Bizyaev from comment #32)
> The bug is present when a file is opened with Inkscape from Dolphin, while
> everything looks right when Inkscape is launched from Kickoff and a file is
> selected then. See the attachments.

I can reproduce the same result as you got. In addition, if I run inkscape from Konsole by command line, it also produce the same issue.

I notice not only tooltips, but also widget style is different. GIMP has the same problem.

(In reply to Wulf from comment #7)
> as written in in gtkrc-2.0:
> # If you do not want KDE to override your GTK settings, select
> # Appearance -> Colors in the System Settings and disable the checkbox
> # "Apply colors to non-KDE4 applications"
> 

Its good to know that there is such option, so I'd expect it would also effect  eclipse tooltips, but it has not (Eclipse Neon SR2 employing gtk3).
Eclipse makes _heavy_ use of links inside tooltip boxes as a major UI paradigma and these being dark blue on dark gray (btw the same as KDE Plasme uses itself!) results in unreadable links.
I could only avoid this by directly patching <code>tooltip { tooltip.background { background-color: ... } }</code> in /usr/share/themes/Breeze/gtk-3.0/gtk.css (as described in https://iwf1.com/how-to-change-gtk-apps-tooltips-text-and-background-color/).

(In reply to bartek from comment #1)
> I can confirm that on update Arch Linux, however there is something more. I
> fo you do:
> find ~ -name "*gtkrc*"

> remove all found content and reconfigure gtk theme in kde systemsettings
> (choosing breeze of course), then things are getting back to normal for a
> session time. Both in inkscape and gimp tooltips consist of white letters on
> black background. After relogin tooltips are not readable again, as shown is
> previous post.

This is consistent with the behavior I'm seeing (Debian plasma 5.8.6). It seems that when you are restoring a session with inkscape running, inkscape starts before the "right" color scheme for the tooltips is loaded, and this ends up with white on white tooltips on inkscape. This is probably an issue in plasma-workspace.

*** Bug 368208 has been marked as a duplicate of this bug. ***

*** Bug 372956 has been marked as a duplicate of this bug. ***

I think it bears repeating that this is not necessarily a bug in the Breeze GTK theme. It's mostly related to System Settings where the 'Apply colors to non-Qt applications' continues to inject information into the theme as though it is Oxygen.

Until Breeze's theme generation script is ready, this behavior should be disabled when an incompatible theme is selected. When the script is ready, it should be activated instead of this behavior, so either way, it will need to be adjusted.

This bug still serves as a predictable 'home base' for the issue, but any complete solution needs to be incorporated over multiple components.

*** Bug 383431 has been marked as a duplicate of this bug. ***

*** Bug 391952 has been marked as a duplicate of this bug. ***

I can confirm removing:
~/.config/gtkrc
~/.config/gtkrc-2.0

Fixes it in OpenSuse 42.2 (x86_64)

I tested this today (Inkscape wasn't honoring the changes in my KDE settings) by modifying ~/.config/gtkrc-2.0

There are a few interesting lines:

# style "ToolTip"
# {
#   bg[NORMAL] = { 0.937, 0.941, 0.945 }
#   base[NORMAL] = { 0.988, 0.988, 0.988 }
#   text[NORMAL] = { 0.192, 0.212, 0.231 }
#   fg[NORMAL] = { 0.192, 0.212, 0.231 }
# }

widget "gtk-tooltip" style "ToolTip"
widget "gtk-tooltips" style "ToolTip"


If I comment out the first call to "gtk-tooltip", all is well.  If I comment out the style, all is well.  I am moving forward with the solution I have pasted here.

Thanks,
Rob

*** Bug 397753 has been marked as a duplicate of this bug. ***

*** Bug 311759 has been marked as a duplicate of this bug. ***

*** Bug 398428 has been marked as a duplicate of this bug. ***

*** Bug 398579 has been marked as a duplicate of this bug. ***

*** Bug 398988 has been marked as a duplicate of this bug. ***

*** Bug 402295 has been marked as a duplicate of this bug. ***

*** Bug 364264 has been marked as a duplicate of this bug. ***

We got patches!

- https://phabricator.kde.org/D18482
- https://phabricator.kde.org/D18485

Git commit c6bab929ac252c053f46d1ddd07d9cc421db22bd by Kai Uwe Broulik.
Committed on 24/01/2019 at 07:35.
Pushed by broulik into branch 'Plasma/5.12'.

[KRDB] Also try wildcard tooltip

It seems as though only tooltip background color was honored whereas text stayed at whatever default window text there was,
leading to potentially unreadable text.
FIXED-IN: 5.12.8

CHANGELOG: Fixed incorrect tooltip colors applied to GTK2 applications leading to unreadable text

Differential Revision: https://phabricator.kde.org/D18482

M  +1    -0    kcms/krdb/krdb.cpp

https://commits.kde.org/plasma-desktop/c6bab929ac252c053f46d1ddd07d9cc421db22bd

Git commit c394dc46fb73aaaf9c4a11a2596e69c0c474299d by Kai Uwe Broulik.
Committed on 24/01/2019 at 07:34.
Pushed by broulik into branch 'Plasma/5.12'.

[KRDB] Write correct tooltip colors into gtkrc in kcminit

kcminit for performance reasons is not desktop settings aware which means it won't load the plasma integration plugin and as such
not apply the color scheme to Qt's widgets.
When writing the GTK config, it would read them from kdeglobals directly. However, for tooltips it would use QToolTip::palette()
which would then use Qt's default palette in kcminit. Use the QPalette we created from kdeglobals to get the tooltip colors instead.

Differential Revision: https://phabricator.kde.org/D18482

M  +4    -6    kcms/krdb/krdb.cpp

https://commits.kde.org/plasma-desktop/c394dc46fb73aaaf9c4a11a2596e69c0c474299d