Community
Participate
Working Groups
When hovering over buttons and tabs the tooltip is total black with no visible text. Using OpenSuse 12.2, KDE 4.9.2. KDE Theme BlackOxygen, Color theme Zion(Reversed). Using eclipse with apperance GTK, while using GTK style Clearlooks. Tried with a default KDE setup with default theme, color and GTK style (non-black color and theme). Same result for eclipse and tooltip text are still not visible. Also tried alternating eclipse appearance, default, classic and gtk. -- Configuration Details -- Product: Eclipse 1.5.0.20120131-1544 (org.eclipse.epp.package.jee.product) Installed Features: org.eclipse.platform 4.2.0.v20120608-135145-9JF7BHV8FyMteji0Oi_ePMz0xuZ8TVo7lV0z0ecb
Created attachment 223100 [details] Screenshot of the problem
I think the problem lies with GTK themes that eclipse are using. If KDE has a dark theme, only the dark GTK theme show tooltip with text. However dark GTK theme are horrible for eclipse (I have tried everyone that comes with OpenSuse 12.2).
I assume this is a dup of Bug 368161.
yep.
*** This bug has been marked as a duplicate of bug 368161 ***
Not a dup of bug 368161. That bug is about custom Javadoc tooltips. This bug is about native OS tooltips on a toolbar button. Sverre, can you please attach a screenshot of a button tooltip in a basic GTK application like gedit or nautilus? I assume this is a general problem with GTK apps in your KDE theme.
Reopening
Created attachment 223343 [details] Gedit tooltip Screenshot of tooltip in Gedit.
(In reply to comment #6) > Not a dup of bug 368161. That bug is about custom Javadoc tooltips. > > This bug is about native OS tooltips on a toolbar button. Sverre, can you > please attach a screenshot of a button tooltip in a basic GTK application > like gedit or nautilus? I assume this is a general problem with GTK apps in > your KDE theme. Added a screenshot of Gedit. Bear in mind that the language is Norwegian in the application, but the tooltip is very much visible in Gedit.
Created attachment 223347 [details] Tooltip for a check box element Another screenshot that shows tooltip over a check box element in Preferences.
Thanks, Sverre. That confirms that the problem is about SWT tooltips. A difference I also see on my Ubuntu 12.04 machine is that the tooltips in gedit have rounded corners while SWT tooltips are full rectangles. However, all tooltips are white-on-black here.
Not sure if the problem is in eclipse. I have the same problem with tooltips in Gimp. It seems like Gnome themes does not work well with KDE using dark color themes.
Maybe bug 386772 could help resolve this?
Created attachment 249689 [details] Black/black tooltip balloon This bug unfortunately still exists in SWT 4.4 on Linux/GTK. It can be reproduced on my system with this code: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet225.java
Related: https://github.com/syncany/syncany/issues/339
I justed tested it with 4.5M1 and it still exists there.
I had several issues as well testing eclipse 4.5 RCx having black backgrounds on tooltips and javadoc view with Fedora22 and GTK Theme Adwaita. I've tried messing up the local gtk theme (css), but that didn't work out well for me. Switching to another theme would work, but since there was no theme I like, it is no option for me. As a workaround to remove the black views, I ended up starting eclipse with launcher option GTK_version 2 - then the black disappears. In eclipse.ini I added --launcher.GTK_version 2 before --launcher.appendVmargs. Of course this is only a workaround, for those who dislike the black background. Maybe this gets fixed until release.
Still there with Mars on ubuntu vivid 15.04. you don't have to abandon gtk3 !!! A workaround is to modify the file gtk-main.css of the theme selected : create if it not exists an hidden folder ~/.themes copy the theme you (definitively) choose. i.e. for "Ambiance": cp -r /usr/share/themes/Ambiance ~/.themes edit ~/.themes/Ambiance/gtk-3.0/gtk-main.css Then change the two values like that : @define-color tooltip_bg_color #ffffaf; @define-color tooltip_fg_color #000000; log-out log-in and enjoy. Of course, you can also create entirely your own theme nevertheless this is definitively something that eclipse should be able to redefine
I did some investigating and found two issues at play here: 1) The draw event was not being handled properly in Gtk3.9+. This means that a draw signal was being emitted, but the drawTooltip() function in ToolTip.java was not being called (i.e., the signal was not being handled). Therefore, nothing was being rendered/painted, leaving a black window instead. This was due to a change in draw/expose events in native Gtk from version 3.9 and up. 2) Once the draw signal was properly connected, only text was being drawn. The background color of the widget was not properly set, so it was showing a black background. This was due to a call to gtk_widget_set_app_paintable() which when set to true, forces the widget to paint its background manually instead of getting it from a style provider or from a parent widget. The widget wasn't painting itself, so the background defaulted to black. The solution I have come up with will have the following behaviour regarding the tooltip background color: Gtk3.10+: the system background color will be applied using CSS styling, if available. If no system background color is specified, the tooltip will inherit its background from its parent container/widget. This was the original intended behaviour. Gtk3.0-3.9: the tooltip will inherit its background from its parent container/widget. The tooltip will still be able to be styled using a system theme, or by setting the background color of its parent. Gtk2: no change in behaviour This solution is pretty flexible as it allows for plenty of options in terms of theme related changes, since most of the new style behaviour will be inherited/CSS, and not hard coded. This means tooltips will work with different system/Eclipse themes as well. I will upload a patch to gerrit after further testing/investigation.
(In reply to Eric Williams from comment #19) > Gtk3.0-3.9: the tooltip will inherit its background from its parent > container/widget. The tooltip will still be able to be styled using a system > theme, or by setting the background color of its parent. Correction: Gtk3.0-3.9 will now use the system background color just as with Gtk3.10+. The only difference in this case is that gtk_widget_override_background_color() will be used, instead of CSS.
New Gerrit change created: https://git.eclipse.org/r/53412
Created attachment 255717 [details] Tooltip is black Tested: https://git.eclipse.org/r/53412/4 Text on Tooltip is visible, but the tooltip is still black when there is a white theme. Can this be fixed also?
@Eric, btw, are there any relevant GTK bugs / related readings for this? E.g about the change in signal handling for expose events? I would be interested in reading about those.
Gerrit change https://git.eclipse.org/r/53412 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=51323e01859c51baa6301398c6c3f54347b47cb4
Patch pushed to master. Thanks Eric.
Created attachment 256498 [details] tooltip/hover screenshot for N20150909-2000 (In reply to Alexander Kurtakov from comment #25) > Patch pushed to master. Thanks Eric. Looking for this fix, I updated my Neon M1 instance (linux/64) to latest nightly N20150909-2000 Build is available Tests results are available (3 of 3 platforms) Wed, 9 Sep 2015 -- 20:00 (-0400) I assume that's already picked up the commit to master? Eclipse is installed/launched with GTK3 org.eclipse.swt.internal.gtk.version=3.14.15 My desktop theme is KDE Plasma5's Breeze. My IDE is themed with the GTK2/3 equivalent, breeze-gtl (https://github.com/dirruk1/gnome-breeze). For editors/content, I've selected an EclipseColorTheme == 'Base16'. WIth that, currently, in IDE, I've still got a barely-readable tooltip (cref: attached, 'tooltip.png') Given @ Eric Williams' comment Gtk3.10+: the system background color will be applied using CSS styling, if available. If no system background color is specified, the tooltip will inherit its background from its parent container/widget. This was the original intended behaviour. (1) Is that expected/acceptable as 'default'? (2) Is CSS styling the appropriate wfix/orkaround? (3) What, exactly, are the path- & naming- conventions for ECLIPSE-only theming? What filename, and where, do I override breeze-gtk's CSS (assuming that's the right parent to be overriding ...) *just* for use by Eclipse?
(In reply to PGNd dev from comment #26) > Created attachment 256498 [details] > tooltip/hover screenshot for N20150909-2000 > > (In reply to Alexander Kurtakov from comment #25) > > Patch pushed to master. Thanks Eric. > > Looking for this fix, I updated my Neon M1 instance (linux/64) to latest > nightly > > N20150909-2000 Build is available Tests results are available (3 of 3 > platforms) Wed, 9 Sep 2015 -- 20:00 (-0400) > > I assume that's already picked up the commit to master? I believe so, run Snippet225 on your machine and see what the result is. If you see no text at all, the patch isn't included. > WIth that, currently, in IDE, I've still got a barely-readable tooltip > (cref: attached, 'tooltip.png') > > > Given @ Eric Williams' comment > > Gtk3.10+: the system background color will be applied using CSS styling, if > available. If no system background color is specified, the tooltip will > inherit its background from its parent container/widget. This was the > original intended behaviour. > > (1) Is that expected/acceptable as 'default'? > > (2) Is CSS styling the appropriate wfix/orkaround? > > (3) What, exactly, are the path- & naming- conventions for ECLIPSE-only > theming? What filename, and where, do I override breeze-gtk's CSS (assuming > that's the right parent to be overriding ...) *just* for use by Eclipse? Your screenshot illustrates a different bug, as that is actually an SWT Browser. Javadoc "tooltips" are not actually tooltips, despite what the name would imply. The bug you are experiencing (unreadable Javadocs, black background, etc.) is still a bug that's open under bug 439884. It's on my to do list. :)
Thanks, I'll relocate the last comment there for posterity.
