Bug 355540 - Tooltips color wrong in gtk applications
Summary: Tooltips color wrong in gtk applications
Status: RESOLVED FIXED
Alias: None
Product: Breeze
Classification: Plasma
Component: gtk theme (show other bugs)
Version: 5.14.4
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: scionicspectre
URL:
Keywords:
: 311759 355879 364264 365937 368208 372956 383431 391952 397753 398579 398988 402295 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-11-18 13:08 UTC by Guo Yunhe
Modified: 2019-01-24 07:36 UTC (History)
50 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.12.8
aaronhoneycutt: Usability-


Attachments
Inkscape launched by Dolphin (3.93 KB, image/png)
2016-12-13 11:48 UTC, Ilya Bizyaev
Details
Inkscape launched by Kickoff (4.69 KB, image/png)
2016-12-13 11:49 UTC, Ilya Bizyaev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Guo Yunhe 2015-11-18 13:08:42 UTC
KDE 5.4.2, Qt 5.5, openSUSE 42.1

By default, tooltips on icons are: white text, dark background. In Firefox and Thunderbird: black text, light gray background. But in Inkscape and GIMP, they are white text, light gray background, which is very hard to read.

http://i.imgur.com/SZWqA79.png

Reproducible: Always
Comment 1 bartek 2015-11-26 12:59:52 UTC
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.
Comment 2 Hugo Pereira Da Costa 2015-11-29 18:29:25 UTC
*** Bug 355879 has been marked as a duplicate of this bug. ***
Comment 3 Frederic Mohr 2015-11-29 21:02:49 UTC
Same problem for me, see also my screenshots in https://bugs.kde.org/show_bug.cgi?id=355879 (closed as duplicate)
Comment 4 zylx 2015-12-23 17:24:20 UTC
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.
Comment 5 G360 2015-12-30 16:58:13 UTC
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
Comment 6 G360 2015-12-30 17:16:03 UTC
Qt4 and Qt5 tooltips
http://i.imgur.com/xr5bQtX.png
Comment 7 Wulf 2015-12-31 11:35:02 UTC
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
Comment 8 scionicspectre 2015-12-31 22:23:48 UTC
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.
Comment 9 Wulf 2016-01-01 15:04:12 UTC
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
Comment 10 scionicspectre 2016-01-02 01:28:06 UTC
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.
Comment 11 ipatrol6010 2016-05-24 03:16:19 UTC
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.
Comment 12 Guo Yunhe 2016-05-24 11:20:38 UTC
(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?
Comment 13 scionicspectre 2016-05-24 21:32:33 UTC
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.
Comment 14 Guo Yunhe 2016-05-25 05:31:38 UTC
(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.
Comment 15 scionicspectre 2016-05-25 07:13:58 UTC
> 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.
Comment 16 skierpage 2016-06-11 20:58:32 UTC
(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?
Comment 17 scionicspectre 2016-06-13 01:00:52 UTC
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.
Comment 18 Rex Dieter 2016-06-13 14:52:26 UTC
" 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.
Comment 19 Gregor Mi 2016-07-02 08:48:12 UTC
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.
Comment 20 Gregor Mi 2016-07-02 08:52:35 UTC
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.
Comment 21 scionicspectre 2016-07-21 13:42:24 UTC
*** Bug 365937 has been marked as a duplicate of this bug. ***
Comment 22 Aaron Honeycutt 2016-08-10 05:50:55 UTC
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
Comment 23 John Carrick Smith 2016-09-19 17:07:54 UTC
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
Comment 24 Gregor Mi 2016-09-19 18:16:05 UTC
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.
Comment 25 Adam 2016-10-08 14:30:16 UTC
I can confirm on Plasma 5.8. It was working on Gimp, but not on Inkscape.
Comment 26 Paul Sommer 2016-11-10 19:46:21 UTC
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.
Comment 27 Wulf 2016-11-10 20:11:07 UTC
@Paul Sommer: did you really unset "apply colors to non-qt applications"?
Comment 28 Paul Sommer 2016-11-10 23:53:56 UTC
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?
Comment 29 Ilya Bizyaev 2016-12-11 13:07:39 UTC
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.
Comment 30 Ilya Bizyaev 2016-12-13 11:48:40 UTC
Created attachment 102762 [details]
Inkscape launched by Dolphin
Comment 31 Ilya Bizyaev 2016-12-13 11:49:30 UTC
Created attachment 102765 [details]
Inkscape launched by Kickoff
Comment 32 Ilya Bizyaev 2016-12-13 11:51:23 UTC
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.
Comment 33 Guo Yunhe 2017-02-09 23:47:11 UTC
(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.
Comment 34 squan 2017-02-16 10:24:43 UTC
(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/).
Comment 35 Maximiliano Curia 2017-04-26 11:01:17 UTC
(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.
Comment 36 Patrick Silva 2017-11-18 14:11:23 UTC
*** Bug 368208 has been marked as a duplicate of this bug. ***
Comment 37 Patrick Silva 2017-11-18 14:28:01 UTC
*** Bug 372956 has been marked as a duplicate of this bug. ***
Comment 38 scionicspectre 2017-11-18 16:39:31 UTC
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.
Comment 39 Nate Graham 2017-12-06 05:48:02 UTC
*** Bug 383431 has been marked as a duplicate of this bug. ***
Comment 40 Christoph Feck 2018-03-27 10:45:03 UTC
*** Bug 391952 has been marked as a duplicate of this bug. ***
Comment 41 Sergey 2018-03-28 03:57:45 UTC
I can confirm removing:
~/.config/gtkrc
~/.config/gtkrc-2.0

Fixes it in OpenSuse 42.2 (x86_64)
Comment 42 Rob Walker 2018-05-30 04:26:14 UTC
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
Comment 43 Nate Graham 2018-08-22 21:45:48 UTC
*** Bug 397753 has been marked as a duplicate of this bug. ***
Comment 44 Nate Graham 2018-08-22 21:46:07 UTC
*** Bug 311759 has been marked as a duplicate of this bug. ***
Comment 45 Nate Graham 2018-09-13 16:38:02 UTC
*** Bug 398428 has been marked as a duplicate of this bug. ***
Comment 46 Nate Graham 2018-09-13 16:46:39 UTC
*** Bug 398579 has been marked as a duplicate of this bug. ***
Comment 47 Patrick Silva 2018-09-23 19:43:57 UTC
*** Bug 398988 has been marked as a duplicate of this bug. ***
Comment 48 Nate Graham 2018-12-27 03:11:25 UTC
*** Bug 402295 has been marked as a duplicate of this bug. ***
Comment 49 Nate Graham 2019-01-17 19:16:31 UTC
*** Bug 364264 has been marked as a duplicate of this bug. ***
Comment 50 Nate Graham 2019-01-23 19:43:34 UTC
We got patches!

- https://phabricator.kde.org/D18482
- https://phabricator.kde.org/D18485
Comment 51 Kai Uwe Broulik 2019-01-24 07:36:24 UTC
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
Comment 52 Kai Uwe Broulik 2019-01-24 07:36:25 UTC
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