Community
Participate
Working Groups
Created attachment 258817 [details] Tooltip in Eclipse Ubuntu 14.04.1 LTS KDE 4.13.3 GTK 3.10.8-0ubuntu1.6 Eclipse tooltip colors, both foreground and background, don't match the preferences set in KDE. The the attachments.
Created attachment 258818 [details] KDE tooltip color preferences
Try and verify the tooltip background in some other application. It's possible that you're seeing just the default settings, and some other configuration is overriding that. (E.g. in XFCE, the tooltip color is governed by the theme but I can override that via the Gnome Color Chooser.)
(In reply to Joachim Durchholz from comment #2) The tooltip appearance is inconsistent between applications. Libre Office and all KDE applications follow the KDE tooltip color preferences. Tooltips in Eclipse, Calculator, GNOME System Monitor and several other applications are white on black regardless of the KDE preferences and the settings in GNOME Color Chooser. Tooltips in GIMP and Chrome are black on gray regardless of the KDE preferences and the settings in GNOME Color Chooser. Eclipse should behave as Libre Office and follow the KDE color preferences when running under KDE. In addition it should give user an option to either follow the system colors or to override them and to set the tooltip colors in Eclipse.
I agree with Sergey for standard tooltips (those on toolbar buttons, view/editor tabs etc.). For tooltips that use Eclipse's color scheme (e.g. the Javadoc tooltip), Eclipse's color scheme must be used, or it will run into color clashes, such as the unreadable dark-blue-on-black Javadoc tooltip that I uploaded as attachment.
Created attachment 258854 [details] Java editor "Source hover background" preference There is already the "Source hover background" preference for the Java editor, but this preference is completely ignored. It also doesn't make sense that there is no matching foreground preference since getting background and foreground preferences from independent sources is a recipe for creating unreadable text. It also doesn't make sense that the preference is defined for the Java editor, but not for Text Editors since even a plain text editor displays hovers.
(In reply to Sergey Prigogin from comment #5) > Created attachment 258854 [details] > Java editor "Source hover background" preference > > There is already the "Source hover background" preference for the Java > editor, but this preference is completely ignored. It also doesn't make > sense that there is no matching foreground preference since getting > background and foreground preferences from independent sources is a recipe > for creating unreadable text. > > It also doesn't make sense that the preference is defined for the Java > editor, but not for Text Editors since even a plain text editor displays > hovers. It does make sense. Let me try to explain. The general rule is that hovers use the following colors from SWT: org.eclipse.swt.SWT.COLOR_INFO_BACKGROUND org.eclipse.swt.SWT.COLOR_INFO_FOREGROUND which are set by SWT according to the OS settings. So far we do not offer preferences in Eclipse for SWT constants taken from the OS, e.g. also no preference for the font used in tables and trees, hence e.g. no Eclipse preference to set the font in most of our views. For the Java source hover, we wanted to use the same color scheme as in the Java editor for syntax coloring, but we still wanted to keep the standard/OS hover background color. On some OSes this did not work well, hence we allowed to adjust the Source hover background for those cases.
Mixing colors from different sources (here: OS for background and syntax highlighting for foreground) does not make sense, because colors interact and hence need to be designed as a whole. That statement is easy to prove, just look at the provided screenshot.
I.e. I do not think Eclipse should get a preference to "apply Eclipse colors to background as well". It should get a preference to activate or deactivate "Use syntax highlighting (uses Eclipse color scheme) for the XXX hover". Though I suspect that such a preference is mostly noise, since I doubt there's any sense in applying OS colors. Eclipse tooltips are not really the same as OS tooltips; even the HTML support in tooltips is a JDK extension that goes far beyond what e.g. GDI offers.
(In reply to Joachim Durchholz from comment #7) > Mixing colors from different sources (here: OS for background and syntax > highlighting for foreground) does not make sense, because colors interact > and hence need to be designed as a whole. > That statement is easy to prove, just look at the provided screenshot. I don't get your point. As said, for normal hovers, we do use OS colors for background and foreground and don't offer any preferences. For the Java source hover, we want to use the same colors as in the editor, with the option to change the default tool tip background. If your point is, that we should use the editor background in the Java source hover, then that's one way to do it, but we decided to give the tool tip background higher priority.
> If your point is, that we should use the editor background in the > Java source hover, then that's one way to do it, but we decided to > give the tool tip background higher priority. What were the reasons for that decision? It's hard to discuss relative merits without that.
(In reply to Joachim Durchholz from comment #10) > > If your point is, that we should use the editor background in the > > Java source hover, then that's one way to do it, but we decided to > > give the tool tip background higher priority. > > What were the reasons for that decision? > It's hard to discuss relative merits without that. That the user perceives this as a hover. On Windows, a hover with a white background, which the editor has, is not looking as expected and not looking good.
A hover with syntax coloring and a toolbar at the bottom isn't looking as expected anyway. Somehow the screenshot upload I referred to earlier didn't make it to the bugzilla; I'll upload a new one, please take a look and tell me if you think that that is looking good.
Created attachment 259006 [details] Hover with system colors in the default "Greybird" theme of Xubuntu. Yes it does have a black background.
(In reply to Joachim Durchholz from comment #13) > Created attachment 259006 [details] > Hover with system colors in the default "Greybird" theme of Xubuntu. Yes it > does have a black background. This is not related to the Java source hover in any way and that's the only one where we (SDK) have separate a preference.
Created attachment 259007 [details] This is how a hover looks with Greybird's system colors. Notice the @Override and the java.util.HashMap links.
Created attachment 259008 [details] The Javadoc looks the same. System hover background does not even apply.
Created attachment 259009 [details] Here is the same Javadoc using the Adwaita theme.
Yes it is. The background color changes with the system preference color. This might be a bug in Javadoc rendering actually.
I think the "Java editor" aspect got mixed up a bit. The issue is the Javadoc hover's background color in the Java editor. Not about a hover using the Java editor's background; that would make sense only for hovers that display Java source, not for rendered Javadoc displays.
(In reply to Joachim Durchholz from comment #19) > I think the "Java editor" aspect got mixed up a bit. > The issue is the Javadoc hover's background color in the Java editor. Right, this (comment 0) is about not picking up the color from the OS (theme), and for sure we want to fix that.
Mass move to 4.7 as M7 is approaching. Please move back in case you are planning to fix it for Neon.
Marking as dup of Bug 500196 (which handles the Javadoc colors). Leo has other bug for the other color inconsistencies. *** This bug has been marked as a duplicate of bug 500196 ***
