Community
Participate
Working Groups
Created attachment 245184 [details] Screenshot RHEL 7 Both the JavaDoc view and the code suggestion popup have bad colours, making the thing unreadable or distracting. I've seen this bug has been opened a few time and always closed as either a works for me or won't fix, stating that this is really a bug in the os theme, but I'm refiling this because all the other bugs (and workaround) are offerend for gtk2 based Eclipse, while this bug is against the gtk3 based version I can download from the main download page. Also, I don't really agree with this point of view, because tooltips look great in the default theme and there is no reason for me to change them, Eclipse just should not use tooltip for those component (or if it really wants to, it needs to be consistent, for instance avoid using conflicting html inside tooltip because it's not reliable). Also, while I can change some aspect of those views (for example, I can change the JavaDoc view background) I can't change all, so I'm forced to leave the defaults as they are. I attach a screenshot to show how this looks in RHEL 7.
Moving to Platform/SWT for analysis.
I'm seeing this issue as well and believe it's happening generally with Eclipse Luna on GTK3 using the Adwaita theme. Various Eclipse widgets seem to inherit the color info foreground/background set by the gtk tooltips but for certain colour schemes (dark background, light foreground) they aren't the best choice (See Bug 399748, Bug 393409). I would propose that a separate widget identifier be given for the tooltip gtk widget used to set the colors used by other Eclipse widgets. With this approach, we give the possibility to create a selector for the Eclipse-specific tooltip-style inheriting widgets and have them styled differently. Note that this is already the case for GTK2 (http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt/Eclipse%20SWT/gtk/org/eclipse/swt/widgets/Display.java#n2330) As an example, Fedora 20 using Adwaita and Eclipse (GTK2) already has a standard selector for all 'gtk-tooltip' widgets. Additionally there exists a selector for 'gtk-tooltips' and those are styled differently. With the proposed patch, themes on GTK3 could use something similar to the below selector to style widgets differently from the standard tooltip color scheme. https://git.eclipse.org/r/30200/ #gtk-tooltips { background-color: alpha(@theme_bg_color, 0.90); color: @theme_fg_color; }
After speaking a bit with Alex, there's some issues with this approach. In particular, the ToolTip widget of Eclipse uses the same COLOR_INFO_{BACKGROUND,FOREGROUND} so this is one case where we'd want to inherit the same style as gtk tooltips. This would have meant that on GTK2 with Adwaita, anything using the Eclipse ToolTip widget (instead of system tooltips) would have had different colours. It seems like the long term solution would be that plugins creating their own custom widgets should refrain from using colours meant for tooltips (COLOR_INFO_*) on components not resembling tooltips (in size). Additionally, Alex mentioned another solution might be to have SWT draw within a particular component's gtk tooltip rather than having widgets use the ToolTip class. This way, all tooltips (eclipse-based, or from gtk) will match.
How about we fix this in the widget that is displaying the JavaDoc and code completion suggestions. For example: BrowserInformationControl has this code: fBrowser.setForeground(display.getSystemColor(SWT.COLOR_INFO_FOREGROUND)); fBrowser.setBackground(display.getSystemColor(SWT.COLOR_INFO_BACKGROUND)); we can change that to something which looks good. Note: I have not tested the above, I am just suggesting with use a smaller net.
(In reply to Sami Wagiaalla from comment #4) > How about we fix this in the widget that is displaying the JavaDoc and code > completion suggestions. > > For example: > BrowserInformationControl has this code: > > fBrowser.setForeground(display.getSystemColor(SWT.COLOR_INFO_FOREGROUND)); > fBrowser.setBackground(display.getSystemColor(SWT.COLOR_INFO_BACKGROUND)); > > we can change that to something which looks good. > > Note: I have not tested the above, I am just suggesting with use a smaller > net. I think this + letting users choose those colours is the best solution, especially considering that there are endless combinations of look and feel settings.
OK. So I'm on Fedora 20 using the eclipse-luna scl[1]. I've aliased my "eclipse" command to eclipse-scl.sh which is in my PATH[2]. I do that in order to be able to just call "eclipse -data <foo>" and it gets passed along. Anyhow, using Luna, the dark backround problem with the adwaita theme is back[3]. Attaching screenshot. I think that's what Roland is referring to, but just making sure :) [1] http://copr.fedoraproject.org/coprs/mbooth/eclipse-luna/ [2] $ type eclipse eclipse is aliased to `eclipse-scl.sh' $ cat bin/eclipse-scl.sh #!/bin/bash ECLIPSE="SWT_GTK3=1 SWT_WEBKIT2=1 eclipse "$@"" scl enable eclipse-luna "$ECLIPSE" [3] https://bugzilla.redhat.com/show_bug.cgi?id=989497
Created attachment 246242 [details] Eclipse luna on F20 with black backround in autocompletion widget.
FWIW, the version of Eclipse Luna in the "eclipse-luna scl" is the same version as we are shipping in the upcoming Fedora 21, so you can see this problem there too if you set the "--launcher.GTK_version" option to 3 in your /etc/eclipse.ini file.
This also effects the "Declarations" view.
Hi, is there any work being done on this bug, or any workaround available? Thanks, Mario
Just as an update, this has been partially resolved. The issue of unreadable entries in the code completion popup should be resolved by http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=716d35d30c1f639a04515188fedd89bb3aaf12bc (Thanks Sami!) . The issue of dark backgrounds in certain views (eg. Javadoc) does not appear to have been addressed yet.
I've reporduced the issue with Luna and GTK3. I will work on this as soon as I have fixed up bug 428852 (dnd).
Occurs not only on RHEL.
*** Bug 460934 has been marked as a duplicate of this bug. ***
Fedora 21, KDE, same issue with black backgrounds on all tooltips, Java content assist, Javadoc and Declaration views. Would be really good to have some kind of fix for 4.5.
Created attachment 252653 [details] Open issues in N20150411-1500
*** Bug 467308 has been marked as a duplicate of this bug. ***
Re targeting this to 4.5.1 as it requires some effort.
*** Bug 471437 has been marked as a duplicate of this bug. ***
Apperently the problem has its roots in GTK templates: Now with 4.5 on Ubuntu with default Ambiance theme you have to modify /usr/share/themes/Ambiance/gtk-3.0/gtk-main.css and set color values for tooltip_bg_color and tooltip_fg_color. This command sets background to pale yellow and foreground to black: sudo sed -i 's/@define-color tooltip_bg_color.*;/@define-color tooltip_bg_color #ffffda;/g' /usr/share/themes/Ambiance/gtk-3.0/gtk-main.css && sudo sed -i 's/@define-color tooltip_fg_color.*;/@define-color tooltip_fg_color #000000;/g' /usr/share/themes/Ambiance/gtk-3.0/gtk-main.css Restart Eclipse and the colors should apply. Prior to 4.5, GTK2-files had to be modified. So with Mars solutions like using gnome-color-chooser don't work and more.
*** Bug 473896 has been marked as a duplicate of this bug. ***
I'm not even sure if this can/should be fixed in SWT itself, SWT just returns the SWT.COLOR_INFO_FOREGROUND and SWT.COLOR_INFO_BACKGROUND values according to the tooltip foreground and background colors which are controlled by the desktop, version of GTK+ (and/or associated themes).
(In reply to Arun Thondapu from comment #22) > I'm not even sure if this can/should be fixed in SWT itself, SWT just > returns the SWT.COLOR_INFO_FOREGROUND and SWT.COLOR_INFO_BACKGROUND values > according to the tooltip foreground and background colors which are > controlled by the desktop, version of GTK+ (and/or associated themes). I believe this could be the issue here. With bug 393409 the problem was related to signals not being hooked properly and painting not even occurring. Here the painting is happening, but the colors are off -- which might not be fixable. I will investigate.
This bug exhibits some odd behaviour. Occasionally the Javadoc tooltips will have visible colors at first, but after the first time they revert to being black. The declaration tab at the bottom seems to have a continuously black background regardless. As Sami pointed out further up, the color can be changed manually using one of the COLOR values in Display.getSystemColor(), however I have noticed that this code doesn't seem to actually change the color of the tooltip. I will investigate this further as it definitely seems like there is a fix to this.
Created attachment 256502 [details] tooltip/hover screenshot for N20150909-2000 relo'd from: https://bugs.eclipse.org/bugs/show_bug.cgi?id=393409 where it was pointed out 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. 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) 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')
(In reply to Sami Wagiaalla from comment #4) > How about we fix this in the widget that is displaying the JavaDoc and code > completion suggestions. > > For example: > BrowserInformationControl has this code: > > fBrowser.setForeground(display.getSystemColor(SWT.COLOR_INFO_FOREGROUND)); > fBrowser.setBackground(display.getSystemColor(SWT.COLOR_INFO_BACKGROUND)); The setBackground and setForeground seem to have zero effect. No matter what color you set using these methods, the Javadoc popup will still have the same color. Surprisingly, this inability to change the color is present on both Gtk2 and Gtk3. It's possible that the color is being eaten somewhere in the WebKit code.
(In reply to Eric Williams from comment #26) The Javadoc view/hovers/tooltips set their background color in HTML, see call hierarchy of org.eclipse.jface.internal.text.html.HTMLPrinter#appendColors(StringBuffer, RGB, RGB). We fetch the default colors like this: private static void cacheColors(Display display) { BG_COLOR_RGB= display.getSystemColor(SWT.COLOR_INFO_BACKGROUND).getRGB(); FG_COLOR_RGB= display.getSystemColor(SWT.COLOR_INFO_FOREGROUND).getRGB(); } However, I don't think there's anything to investigate there. This bug has collected too many different topics and should be closed. If you want to request configurable foreground/background colors for custom tooltips, look for a bug in Platform/UI, or file a new one if none exists. However, be warned that this will not magically adjust every client of SWT.COLOR_INFO_BACKGROUND. Furthermore, it's not clear which tooltips would belong into this new category. If you look at references to org.eclipse.jface.window.ToolTip, there are many that are quite close to native tooltips. IMO, we shouldn't introduce multiple kinds of tooltips. (In reply to Eric Williams from comment #24) > This bug exhibits some odd behaviour. Occasionally the Javadoc tooltips will > have visible colors at first, but after the first time they revert to being > black. I can't reproduce that, but may be connected to bug 420653. > The declaration tab at the bottom seems to have a continuously black > background regardless. The Declaration view in attachment 252653 [details] is indeed wrong. Filed bug 477487 to fix that.
Created attachment 256591 [details] Comparison between GNOME3 and SWT tooltips (In reply to Markus Keller from comment #27) > The Javadoc view/hovers/tooltips set their background color in HTML, see > call hierarchy of > org.eclipse.jface.internal.text.html.HTMLPrinter#appendColors(StringBuffer, > RGB, RGB). > > We fetch the default colors like this: > > private static void cacheColors(Display display) { > BG_COLOR_RGB= display.getSystemColor(SWT.COLOR_INFO_BACKGROUND).getRGB(); > FG_COLOR_RGB= display.getSystemColor(SWT.COLOR_INFO_FOREGROUND).getRGB(); > } This explains a lot. It's important to note that Eclipse tooltips (such as Javadocs) look particularly bad on stock GNOME3 since SWT loses the alpha value. This is mainly due to a shortcoming in the way SWT handles colors, which is a totally different issue. The lack of transparency means that dark tooltips now have a solid black background, which can look particularly harsh with white text. See the attached screenshot: the Gedit window has a transparent tooltip, whereas the SWT tooltip from Snippet225 does not. > However, I don't think there's anything to investigate there. This bug has > collected too many different topics and should be closed. If you want to > request configurable foreground/background colors for custom tooltips, look > for a bug in Platform/UI, or file a new one if none exists. This sounds reasonable. > However, be warned that this will not magically adjust every client of > SWT.COLOR_INFO_BACKGROUND. I think once the colors in SWT are fixed (i.e. fully ported from using GdkColor to GdkRGBA with working alpha) this issue will be a lot less prevalent.
Marking as closed for now as per Markus' comments (comment #27). The issue lies outside of SWT and requires design changes to be fixed.
I just want to post a workaround for those with GNOME 3.18's default Adwaita theme and Eclipse Mars having black tooltips and ctrl+o screens. The easiest way to overcome this problem is to provide an overriding css in ~/.config/gtk-3.0/gtk.css à la: .tooltip { color: black; background-color: white; border-width: 1px; border-color: aliceblue; text-shadow: none; } NB! 1) Do not use transparency in background-color. This would make Eclipse behave strangely (i.e. it could work at first, but then will flip to black or gray) 2) Modifying a theme (i.e. creating a new theme by copying Adwaita entirely or simple importing its css from resource, then appending the above class) does not work for some reason. The color could be changed, but the background remains the same.
@Aleksei Lissitsin Your workaround worked for me. Thanks a lot.
(In reply to Aleksei Lissitsin from comment #30) > 2) Modifying a theme (i.e. creating a new theme by copying Adwaita entirely > or simple importing its css from resource, then appending the above class) > does not work for some reason. The color could be changed, but the > background remains the same. Have you tried to define .gtk-tooltip { color: black; background-color: white; border-width: 1px; border-color: aliceblue; text-shadow: none; } See https://github.com/iloveeclipse/clearlooks-phenix/blob/master/gtk-3.0/applications.css. I have not yet tried with GNOME 3.18, but GNOME 3.16 (or whatever version Fedora 21 has right now) seem to work.
(In reply to Andrey Loskutov from comment #32) > (In reply to Aleksei Lissitsin from comment #30) > > 2) Modifying a theme (i.e. creating a new theme by copying Adwaita entirely > > or simple importing its css from resource, then appending the above class) > > does not work for some reason. The color could be changed, but the > > background remains the same. > > Have you tried to define > .gtk-tooltip { > color: black; > background-color: white; > border-width: 1px; > border-color: aliceblue; > text-shadow: none; > } It does not seem to have an effect either.
(In reply to Aleksei Lissitsin from comment #30) > I just want to post a workaround for those with GNOME 3.18's default Adwaita > theme and Eclipse Mars having black tooltips and ctrl+o screens. > > The easiest way to overcome this problem is to provide an overriding css in > ~/.config/gtk-3.0/gtk.css à la: > .tooltip { > color: black; > background-color: white; > border-width: 1px; > border-color: aliceblue; > text-shadow: none; > } Your workaround also works on KDE Plasma 5.5 with Eclipse MARS.1 - thanks! Note that Eclipse Preferences specify under General > Appearance: - Theme: GTK - Color and Font theme: Default (current) so I'm not sure the theme selected in the KDE settings (Breeze in my case) is relevant at all.
(In reply to Aleksei Lissitsin from comment #30) > I just want to post a workaround for those with GNOME 3.18's default Adwaita > theme and Eclipse Mars having black tooltips and ctrl+o screens. > > The easiest way to overcome this problem is to provide an overriding css in > ~/.config/gtk-3.0/gtk.css à la: > .tooltip { > color: black; > background-color: white; > border-width: 1px; > border-color: aliceblue; > text-shadow: none; > } > > NB! > 1) Do not use transparency in background-color. This would make Eclipse > behave strangely (i.e. it could work at first, but then will flip to black > or gray) > 2) Modifying a theme (i.e. creating a new theme by copying Adwaita entirely > or simple importing its css from resource, then appending the above class) > does not work for some reason. The color could be changed, but the > background remains the same. This workaround worked for me partially in Debian 8.3 XFCE. I created the file manually and added your content. After that, the eclipse tooltip ineed became while background and black text: https://dl.dropboxusercontent.com/u/14154631/eclipse_tooltip1.png The problem is that in Debug view, under "object lookup" the line is hovered and that hover is light gray and the hovered text is white making it still impossible to read... https://dl.dropboxusercontent.com/u/14154631/eclipse_tooltip2.png I was wondering is there also a fix for this?
Created attachment 260198 [details] Eclipse C development tool view (In reply to Andrey Loskutov from comment #32) > (In reply to Aleksei Lissitsin from comment #30) > > 2) Modifying a theme (i.e. creating a new theme by copying Adwaita entirely > > or simple importing its css from resource, then appending the above class) > > does not work for some reason. The color could be changed, but the > > background remains the same. > > Have you tried to define > .gtk-tooltip { > color: black; > background-color: white; > border-width: 1px; > border-color: aliceblue; > text-shadow: none; > } > > See > https://github.com/iloveeclipse/clearlooks-phenix/blob/master/gtk-3.0/ > applications.css. I have not yet tried with GNOME 3.18, but GNOME 3.16 (or > whatever version Fedora 21 has right now) seem to work. The workaround does not fix the problem in Eclipse C development tools (CDT), but only fixes it for Java/Java EE view. I am wondering why there is such difference. My system: Fedora 23 KDE using upstream Eclipse
1. Eclipse 4.6 completely breaks javadoc "tooltip" on Fedora 23 under different GTK3 themes, and on Ubuntu 16.04 Gnome 3.18 and Gnome 3.20! 2. However, Eclipse 4.5 works fine with the .gtk-tooltip CSS fix reported earlier. 3. Even more so, Eclipse 4.5 on Gnome 3.20 allows for customizable javadocs from within the Preferences as intended! But not Eclipse 4.6 :( IMHO, it is a scandal that this issue is still has not been resolved by now after so many years. This must be the highest priority for the entire Eclipse team. This affects the entire Eclipse Linux community, badly and needlessly; and totally invalidates the entire point of SWT and making Eclipse on native widgets. Please fix it ANYHOW, as ugly internally as it may be, if need to be. Otherwise, it looks like you're making great cars with no functioning wheels! Eclipse users shouldn't be browsing for various GTK3 themes just to make Eclipse work. In addition, there is NO GUIDANCE from Eclipse team which themes might even work, and when they work, as the case with Eclipse 4.5, you break it with the newest version and w/o recourse! Enough is enough! Change the priority of this issue to critical and FIX it ASAP!
(In reply to David Tesler from comment #38) > 1. Eclipse 4.6 completely breaks javadoc "tooltip" on Fedora 23 under > different GTK3 themes, and on Ubuntu 16.04 Gnome 3.18 and Gnome 3.20! > 2. However, Eclipse 4.5 works fine with the .gtk-tooltip CSS fix reported > earlier. > 3. Even more so, Eclipse 4.5 on Gnome 3.20 allows for customizable javadocs > from within the Preferences as intended! But not Eclipse 4.6 :( > > IMHO, it is a scandal that this issue is still has not been resolved by now > after so many years. This must be the highest priority for the entire > Eclipse team. This affects the entire Eclipse Linux community, badly and > needlessly; and totally invalidates the entire point of SWT and making > Eclipse on native widgets. > > Please fix it ANYHOW, as ugly internally as it may be, if need to be. > Otherwise, it looks like you're making great cars with no functioning > wheels! Eclipse users shouldn't be browsing for various GTK3 themes just to > make Eclipse work. In addition, there is NO GUIDANCE from Eclipse team which > themes might even work, and when they work, as the case with Eclipse 4.5, > you break it with the newest version and w/o recourse! > > Enough is enough! Change the priority of this issue to critical and FIX it > ASAP! Well said, well said. Considering also that the bug dates back even before 2014
(In reply to David Tesler from comment #38) > Enough is enough! Change the priority of this issue to critical and FIX it > ASAP! I don't think your comment is appropriate, and IMHO very offensive. Please take a deep breath. You haven't paid a dime for Eclipse, and also consider that most of the Eclipse UI committers do they work in a free time. Please next time be more constructive and probably even try to contribute: https://wiki.eclipse.org/Platform_UI/How_to_Contribute.
1. It's been here for YEARS 2. It makes coding in Eclipse difficult to impossible for ALL related products 3. It's reproducible and localized 4. Since Eclipse 4.6, no known workarounds exist, nor provided 5. It's negating all the hard work done by the Eclipse development community to improve the product - compare it to IntelliJ or NetBeans in terms of GUI, their GUI is good enough on any platform and don't depend on native quirks. 6. It CAN be fixed relatively quickly and easily; given, it might be a number of places to deal with, but w/o much danger to the rest of the code, as we talking here about ONLY background/foreground colors for particular screens. NO, it is not offensive to ask so little for what affects so much (Eclipse on Linux almost unusable). Regards, David
(In reply to David Tesler from comment #41) > 6. It CAN be fixed relatively quickly and easily Please, if you *really* care, go ahead and start to contribute: https://wiki.eclipse.org/Platform_UI/How_to_Contribute
I am not an Eclipse developer. However, here is my proposal for a hotfix: 1. introduce an eclipse.ini and/or cmd switch like this: -xx.javadoc.color=fg:<color value>, bg:<color value> 2. if (the switch is present) then (only on Linux) use the colors otherwise (get colors as usual); roughly as shown below. Color getEclipseJavaDocColor() { Optional<Color> javaDocSwitchValue = getEclipseIniSwitchForJavaDoc(); return "Linux".equals(System.getProperty("os.name")) ? javaDocSwitchValue.orElse(getNormalColor()) : getNormalColor(); } 3. it's also possible to check for the theme (dark or light), and supply the predefined color values in case of the switch is present w/o values. 4. then it will take a couple of trivial modifications in the JavaDoc color handling code to deal with this annoying bug. Regards, David
The proper fix for this bug is to fix bug 477950, which I am hoping to finish for the Oxygen release cycle, possibly even Neon.1.
It's great news! However, for now Eclipse 4.6 is unusable with regard of JavaDoc on Linux, on Gnome 3.18 and 3.20, and this can't be fixed on any GTK3 theme and no known workarounds. Eclipse 4.5.2 actually works on Gnome 3.20 and allows changing the colors from within the preferences. Clearly, there is some regression bug been introduced here. What I am asking is a temporary fix till you come up with the solution. IMHO, this is urgent; if it cannot be in the Eclipse 4.6 release, then just provide an emergency fix delivered as a patch via Eclipse New Software (p2 repo), not unlike the JDT patches.
(In reply to David Tesler from comment #45) > It's great news! However, for now Eclipse 4.6 is unusable with regard of > JavaDoc on Linux, on Gnome 3.18 and 3.20, and this can't be fixed on any > GTK3 theme and no known workarounds. > > Eclipse 4.5.2 actually works on Gnome 3.20 and allows changing the colors > from within the preferences. Clearly, there is some regression bug been > introduced here. > > What I am asking is a temporary fix till you come up with the solution. > IMHO, this is urgent; if it cannot be in the Eclipse 4.6 release, then just > provide an emergency fix delivered as a patch via Eclipse New Software (p2 > repo), not unlike the JDT patches. This is an important issue indeed. Eric has started working on replacing GtkColor (gtk2) with GtkRGBA (gtk3). Once that's fixed, it should fix the black tooltip also. I'm somewhat against a quick fix as it may slow down development of the proper solution to this issue. Eclipse is quite usable with the black tooltips (It's not pretty I agree, but I can still use it for my needs). I think instead we should put more effort into a good long term fix for this.
Sorry for going back and forth on this! My MAJOR complaint is not the JavaDoc text background/foreground color, but the JavaDoc links' foreground color; it's really bad and unintelligible! If this could be fixed quickly before Eclipse 4.6 release, that would be greatly appreciated by entire Eclipse Linux community, IMHO! Cordially, David
The Javadoc colors are reworked in Bug 501742 and for the tooltips are covered by Bug 381010. I mark this bug as dup of Bug 501742. *** This bug has been marked as a duplicate of bug 501742 ***
