Community
Participate
Working Groups
Created attachment 263752 [details] Screenshot Similar to Bug 497984 for general popups the Javadoc hover and Javadoc view should use colors which makes them readable. See screenshot.
(In reply to Lars Vogel from comment #0) > Created attachment 263752 [details] > Screenshot I can read all the text in that image.
(In reply to Dani Megert from comment #1) > I can read all the text in that image. I'm puzzled by the intent of this statement. Does it mean that every user should be able to read all the text in that image? If not, how is this statement relevant to this bug?
(In reply to Dani Megert from comment #1) > (In reply to Lars Vogel from comment #0) > > Created attachment 263752 [details] > > Screenshot > > I can read all the text in that image. IIRC, the issue becomes clicking the links in the path, i.e. hovering over the "org.eclipse.swt.events.SelectionListener" becomes a very dark blue, which is hard to read. The other thing too is that this is being rendered in a Browser widget, not technically a tooltip. Using the default COLOR_WIDGET_BACK/FOREGROUND (or better yet, COLOR_LIST_BACK/FOREGROUND) would seem more appropriate. It's also worth noting that on Fedora/GNOME Adwaita the screenshot Lars posted would be white on black, not orange.
(In reply to Sergey Prigogin from comment #2) > (In reply to Dani Megert from comment #1) > > > I can read all the text in that image. > > I'm puzzled by the intent of this statement. Does it mean that every user > should be able to read all the text in that image? If not, how is this > statement relevant to this bug? If everyone can see the image correctly, how is the image relevant to this bug? ;-)
(In reply to Dani Megert from comment #4) > If everyone can see the image correctly, how is the image relevant to this > bug? ;-) Agree with this statement, but I cannot read the dark blue text on the black background without straining my eyes. This means that not everyone can read all the text in the attached image.
Come on, this is pointless discussion. We all agree that there is a problem, right? Even if readability is questioned (readable for some, not for others) the fact that the colors are entirely out of sync with the rest of the workbench makes these views look quite alien and not in place and make us look quite amateurish. FWIW, these out of order black backgrounds are one of the most common complain I receive. This inconsistency just hurts too many people eyes.
(In reply to Alexander Kurtakov from comment #6) > Come on, this is pointless discussion. We all agree that there is a problem, > right? Even if readability is questioned (readable for some, not for others) > the fact that the colors are entirely out of sync with the rest of the > workbench makes these views look quite alien and not in place and make us > look quite amateurish. > FWIW, these out of order black backgrounds are one of the most common > complain I receive. This inconsistency just hurts too many people eyes. In most cases the underlying problem comes from bad values read by SWT (In reply to Sergey Prigogin from comment #5) > (In reply to Dani Megert from comment #4) > > If everyone can see the image correctly, how is the image relevant to this > > bug? ;-) > > Agree with this statement, but I cannot read the dark blue text on the black > background without straining my eyes. This means that not everyone can read > all the text in the attached image. Sorry, I was looking at the main text. I agree the blue link color is distracting. My first question would be: Is the black background desired in this case (looking at the editor background, which is white, it does not seem to run with the Dark theme) - I guess not. For the case where an unwanted black color is used for COLOR_INFO_BACKGROUND SWT could fix that and all clients would benefit. Another approach would be for SWT to allow setting that value. That way we could at offer a preference to set it. Of course same with the fg color. Again, this would help all clients not just the Javadoc view and hover.
(In reply to Dani Megert from comment #7) > (In reply to Alexander Kurtakov from comment #6) > > Come on, this is pointless discussion. We all agree that there is a problem, > > right? Even if readability is questioned (readable for some, not for others) > > the fact that the colors are entirely out of sync with the rest of the > > workbench makes these views look quite alien and not in place and make us > > look quite amateurish. > > FWIW, these out of order black backgrounds are one of the most common > > complain I receive. This inconsistency just hurts too many people eyes. > > In most cases the underlying problem comes from bad values read by SWT (In > reply to Sergey Prigogin from comment #5) > > (In reply to Dani Megert from comment #4) > > > If everyone can see the image correctly, how is the image relevant to this > > > bug? ;-) > > > > Agree with this statement, but I cannot read the dark blue text on the black > > background without straining my eyes. This means that not everyone can read > > all the text in the attached image. > > Sorry, I was looking at the main text. I agree the blue link color is > distracting. > > My first question would be: Is the black background desired in this case > (looking at the editor background, which is white, it does not seem to run > with the Dark theme) - I guess not. For the case where an unwanted black > color is used for COLOR_INFO_BACKGROUND SWT could fix that and all clients > would benefit. These colors come from the system theme and these constants are improperly used based on assumptions that used to be true in the past. Overriding the color would cause nothing but further weirdness. > Another approach would be for SWT to allow setting that > value. That way we could at offer a preference to set it. Of course same > with the fg color. Again, this would help all clients not just the Javadoc > view and hover. Again, having a way to override colors in some way is one thing and I agree with that but the constants used now should stay the way they are for cases where they used properly (aka COLOR_INFO_* is for tooltip/non-interactive components).
(In reply to Alexander Kurtakov from comment #8) > Again, having a way to override colors in some way is one thing and I agree > with that but the constants used now should stay the way they are for cases > where they used properly (aka COLOR_INFO_* is for tooltip/non-interactive > components). Javadoc hovers *are* info popups / tooltips. If you say they should stay, then we won't fix them. For Javadoc view we already have a preference for the bg.
(In reply to Dani Megert from comment #9) > (In reply to Alexander Kurtakov from comment #8) > > Again, having a way to override colors in some way is one thing and I agree > > with that but the constants used now should stay the way they are for cases > > where they used properly (aka COLOR_INFO_* is for tooltip/non-interactive > > components). > > Javadoc hovers *are* info popups / tooltips. If you say they should stay, > then we won't fix them. For Javadoc view we already have a preference for > the bg. I would argue that they are popup widgets: but they are not tooltips. A tooltip is usually a short informative blurb about something when the user hovers. They don't allow for any user interaction and disappear when given focus. The Javadoc hover is a popup browser, as the user can click around in it, display different information, and even give the popup focus and move it around.
(In reply to Eric Williams from comment #10) > (In reply to Dani Megert from comment #9) > > (In reply to Alexander Kurtakov from comment #8) > > > Again, having a way to override colors in some way is one thing and I agree > > > with that but the constants used now should stay the way they are for cases > > > where they used properly (aka COLOR_INFO_* is for tooltip/non-interactive > > > components). > > > > Javadoc hovers *are* info popups / tooltips. If you say they should stay, > > then we won't fix them. For Javadoc view we already have a preference for > > the bg. > > I would argue that they are popup widgets: but they are not tooltips. > > A tooltip is usually a short informative blurb about something when the user > hovers. They don't allow for any user interaction and disappear when given > focus. The Javadoc hover is a popup browser, as the user can click around in > it, display different information, and even give the popup focus and move it > around. I disagree here, sorry. It's a tooltip and the info color is the correct choice. We can either leave it as is or go forward as I proposed before.
(In reply to Eric Williams from comment #10) Agree.
(In reply to Sergey Prigogin from comment #12) > (In reply to Eric Williams from comment #10) > > Agree. I disagree. No matter what, on Windows I want those to use the hover colors and as said before we have two options: - only fix the problem for hover and Javadoc view by providing preferences - allow to set the COLOR_INFO_* colors Using LIST color is just wrong here.
(In reply to Dani Megert from comment #9) > Javadoc hovers *are* info popups / tooltips. Opinion statements without supporting arguments are not likely to persuade others. While everybody has a right to express his/her opinion, the only way for the minority point of view to win is to attract more people to their side. This is possible only by providing persuasive arguments. The definition of tooltip given in comment #10 seems pretty accurate. Javadoc popups don't fit that definition and therefore are not tooltips.
(In reply to Dani Megert from comment #13) > (In reply to Sergey Prigogin from comment #12) > > (In reply to Eric Williams from comment #10) > > > > Agree. > > I disagree. No matter what, on Windows I want those to use the hover colors > and as said before we have two options: > - only fix the problem for hover and Javadoc view by providing preferences > - allow to set the COLOR_INFO_* colors > > Using LIST color is just wrong here. And I disagree here too. The fact that you want to use COLOR_INFO constants is either because the colors on windows blend in the whole workbench color set or because the exposed constants are modeled after the Win32 color set neglecting differencies in others (note that Cocoa explicitly hardcodes these colors going against SWT principles of matching the underlying UI toolkit for that sake). Setting COLOR_INFO_* is not the right thing to do - these are constants and they should stay clear about their purpose in the way the OS/UI toolkit designed them - what we need is additional settable color set for the views in question and on win32 them being set to COLOR_INFO_* and to explicitly defined colors on other OSes.
Created attachment 264083 [details] White popup preview screenshot
(In reply to comment #13) > (In reply to Sergey Prigogin from comment #12) > > (In reply to Eric Williams from comment #10) > > > > Agree. > > I disagree. No matter what, on Windows I want those to use the hover colors and Well, I may be wrong, but there is my line of thought: There are similarities to a tooltip, but wiki [1] says that a tooltip is only for showing information, you don't interact with the tooltip. In our case, we can actually go into the tooltip and perform things like open code in a new tab and open the JavaDoc view. On the grounds that we interact with the popup widget, it is more of a hoverbox; as such it bears similarity to the outline view or any other interactive popup rather than a tooltip. Further, the javaDoc is not just a popup, it is also a 'view' that can be shown in a CTabFolder. I.e that is not a tooltip at all. Further, from a technical point of view, this is a browser widget with some buttons. It does not utilize a native swt 'tooltip' widget but is constructed of other widgets that don't have anything to do with tooltips. > as said before we have two options: > - only fix the problem for hover and Javadoc view by providing preferences Users shouldn't have to go into preferences to fix a generic usability issue. This is not really a feasible option from a UI design point of view. It should work out of the box. > - allow to set the COLOR_INFO_* colors We shouldn't hack OS colors unless there is really good cause. The reason for that is that we would break GTK theames that have their own colors > Using LIST color is just wrong here. I can't just yet say if using LIST color is "right or wrong" here. I need to investigate further. However I can say that using COLOR_INFO_* for a hovebox is incorrect on the grounds that we're dealing with a hoverbox and not a tooltip. Thus I think COLOR_INFO_ has to go. I'm working with the platform.ui source code at the moment. I got javadoc hoverbox colors to be white/black to match the rest of the U.I (See attached screenshot). I'm now working on getting the javadoc view-part colors to match the rest of the U.I also. ~Patch in progress. Please wait. [1] https://en.wikipedia.org/wiki/Tooltip [2] https://en.wikipedia.org/wiki/Hoverbox
Since there is already a preference for Javadoc view background, it makes sense to either reuse this preference for Javadoc popups or introduce a separate preference for the Javadoc popup background. Reusing any other existing preference or color would likely cause problems.
(In reply to Alexander Kurtakov from comment #15) > Setting COLOR_INFO_* is not the right thing to do Yes, I agree thinking about it over the weekend. We don't want that the hovers on the native widgets use a different color. (In reply to Sergey Prigogin from comment #18) > Since there is already a preference for Javadoc view background, it makes > sense to either reuse this preference for Javadoc popups or introduce a > separate preference for the Javadoc popup background. Reusing any other > existing preference or color would likely cause problems. Yes, I agree. We should use the Javadoc view color for hovers too. And we should also introduce the foreground color. Even more, we should make them styleable, so that the Dark theme can also set a dark color. Currently this isn't possible.
(In reply to Dani Megert from comment #19) > Even more, we should make them styleable, so that the Dark theme can also set a dark color. Currently this isn't possible. If we have a preference, we can "style" this via our CSS engine, similar to what we do with the font and color settings for the Java editor.
Status update: From my investigation, there are two separate components in separate repositories: 1) Colors for (Hoverbox) that pops up when you mouse over a token is set in: Repo: eclipse.platform.text (org.eclipse.jface.internal.text).html.HTMLPrinter.java:cacheColors(Display) BG_COLOR_RGB= display.getSystemColor(SWT.COLOR_INFO_BACKGROUND).getRGB(); FG_COLOR_RGB= display.getSystemColor(SWT.COLOR_INFO_FOREGROUND).getRGB(); 2) Colors for JavaDoc view is set in: Repo: Eclipse.jdt.ui (org.eclipse.jdt.internal.ui).infoviews.AbstractInfoView.java:inititalizeColors() - Foreground color is hard-coded: ~ 318: setForeground(display.getSystemColor(SWT.COLOR_INFO_FOREGROUND)); - Background color is retrieved from plugin.xml ~1062: value="COLOR_INFO_BACKGROUND" id="org.eclipse.jdt.ui.JavadocView.backgroundColor"> Setting those to something white (ex COLOR_LIST_*) on Gtk3 with white theme, makes Hoverbox and JavaDoc view have a white background and black text (as per screeshot). I'm going to work on writing two patches for this.
(In reply to Dani Megert from comment #19) > Yes, I agree. We should use the Javadoc view color for hovers too. And we > should also introduce the foreground color. Even more, we should make them > styleable, so that the Dark theme can also set a dark color. Currently this > isn't possible. Actually, we should introduce separate fg and bg color preferences for non-native hovers in Platform Text, so that other editors and "views" can also use them, e.g. the new Generic Editor. The current Javadoc view background could use the new one by default.
I found a related bug: Bug 313943 – [hovering] Java source hovers not readable using Ubuntu 10.04 (white-on-black tooltips) https://bugs.eclipse.org/bugs/show_bug.cgi?id=313943 If you hold 'shift' while hovering over something, a hover-tip is shown. This one is actually looks OK on the current Eclipse build. Maybe we should implement a similar fix..
Created attachment 264151 [details] Using JavaEditor colors - Black theme
Created attachment 264152 [details] Using JavaEditor colors - Classic theme
I experimented with COLOR_LIST. Does't seem to work that well on Dark theme. I propose as solution to use the colors of current JavaEditor. ex: RGB background = PreferenceConverter.getColor(preferenceStore, AbstractTextEditor.PREFERENCE_COLOR_BACKGROUND); RGB foreground = PreferenceConverter.getColor(preferenceStore, AbstractTextEditor.PREFERENCE_COLOR_FOREGROUND); Attached screenshots of how it looks on Black/white themes. That should ensure consistent colours. All modifications would be in JDT.ui Thoughts?
(In reply to Leo Ufimtsev from comment #26) Using editor colors results in readable text but limits user's ability to customize the look of the IDE. I personally like the Javadoc colors to be off white (FFFFDD) with the classic theme. I agree with the comment #22.
(In reply to Dani Megert from comment #22) > Actually, we should introduce separate fg and bg color preferences for > non-native hovers in Platform Text, so that other editors and "views" can > also use them, e.g. the new Generic Editor. The current Javadoc view > background could use the new one by default. This makes a lot of sense, +1. (In reply to Leo Ufimtsev from comment #26) > I experimented with COLOR_LIST. Does't seem to work that well on Dark theme. > > I propose as solution to use the colors of current JavaEditor. > > ex: > RGB background = PreferenceConverter.getColor(preferenceStore, > AbstractTextEditor.PREFERENCE_COLOR_BACKGROUND); > > RGB foreground = PreferenceConverter.getColor(preferenceStore, > AbstractTextEditor.PREFERENCE_COLOR_FOREGROUND); This is a good idea but I think having a "non-native hover" color preference is even better, as it gives more customization power to the user.
(In reply to comment #22) > (In reply to Dani Megert from comment #19) > > Yes, I agree. We should use the Javadoc view color for hovers too. And we > > should also introduce the foreground color. Even more, we should make them > > styleable, so that the Dark theme can also set a dark color. Currently this > > isn't possible. > > Actually, we should introduce separate fg and bg color preferences for > non-native hovers in Platform Text, so that other editors and "views" can also > use them, e.g. the new Generic Editor. The current Javadoc view background could > use the new one by default. Interesting. I've been doing some tinkering and analysis. My observation and suggested course of action: - Note: JavadocView.java and JavadocHover.java are separate pieces of code. - JavadocView can have it's background defined via Preferences -> General -> Appearance ->colors and fonts -> Java -> Javadoc view background. However, javadocView cannot have it's text color set. I've created a bug to add the javadocView text option: Bug 501452: Add option to set JavaDocView's text color - JavadocHover does not use the color defined in "Colors and Font's" preference. Instead it uses a hard-coded color. Proposed course of action: - I'll implement: Bug 501452: Add option to set JavaDocView's text color - I'll adapt the defaults such that they can be read on all platforms easily (inc gnome3 white and dark themes). (In a sub-bug) - I'll update JavaDocHover.java so that it uses the colors defined in "Colors and Font's" instead of the hard-coded once. (In a sub-bug) Once that is done, if there is motivation, someone is welcome to further improve the patch so that there is some kind of 'generalized' hoverbox color options. However this will be out of the scope of this bug as this bug only deals with JavadocView and javadocHover. Do we have a consensus on the above, or are there any concerns? (+-1?)
Could anyone review the sub-task for this task? Bug 501452 – Add option to set JavaDocView's text color https://bugs.eclipse.org/bugs/show_bug.cgi?id=501452
@All involved. I proposed two possible solutions to the last child bug. (Default color). If you have time, please see child task and leave feedback: Bug 501742 – Default Javadoc text and background color should use colors consistent with Java editor background/foreground.
I implemented a solution that should hopefully make everyone happy. No visual changes on Win32/Cocoa, but on Gtk Javadoc looks nice. If someone has jdt/platform.ui contributor rights, please review: https://bugs.eclipse.org/bugs/show_bug.cgi?id=501742 Thank you
Bug 505738 seems to contain the latest relevant discussions.
(In reply to Dani Megert from comment #33) > Bug 505738 seems to contain the latest relevant discussions. Yes indeed. Quick overview: Current plan: - Implement a generic preference in Workbench.ui, which can be used by various plugins (including JDT). (Implementation details pending in Bug 505738) - Change JDT's JavadocView and JavadocHover to use that preference - Update the e4-darktheme to style the generic preference so that Javadoc would look proper on Dark theme. - (then fix other elements, e.g problem assist, by using that preference. But this will be dealt with in other bugs ticket).
Thanks Noopur for the fast review and Leo for the patch. Leo, can you add an entry to the N&N M4?
(In reply to Lars Vogel from comment #35) > Thanks Noopur for the fast review and Leo for the patch. Leo, can you add an > entry to the N&N M4? There are still a few colors that are broken. Ex problem assist dialogue. I'll try to get that fixed and them lump them together into a N&N.
Side note: this bug has a related stackoverflow with 13k views over the last 4 years: http://stackoverflow.com/questions/10383467/eclipse-javadoc-background-color-is-black
Leo, please provide a N&N for M4 which is arriving next week.
All child bugs were fixed. This issue is resolved.
(In reply to Lars Vogel from comment #38) > Leo, please provide a N&N for M4 which is arriving next week. @ Lars. Thank you for reminder. I submitted a patch here: https://git.eclipse.org/r/#/c/86110/
*** Bug 484742 has been marked as a duplicate of this bug. ***
I can see two dependent bugs that are not resolved. Reopening for now.
(In reply to Leo Ufimtsev from comment #42) > I can see two dependent bugs that are not resolved. Reopening for now. I don't see these bugs as dependent - maybe just close this one and keep the reference as see also. P.S. Depends on means the other bug has to be fixed first and I don't see such relation here.
(In reply to Alexander Kurtakov from comment #43) > (In reply to Leo Ufimtsev from comment #42) > > I can see two dependent bugs that are not resolved. Reopening for now. > > I don't see these bugs as dependent - maybe just close this one and keep the > reference as see also. > P.S. Depends on means the other bug has to be fixed first and I don't see > such relation here. Ah yea, that's a good point. Thanks. I think I originally reopened it for this guy: (now fixed) Bug 507062 - Fix black strip of color in JavaDocHover But the other guy doesn't seem dependent. I made it a reference instead: Bug 512882 - [KDE?] Strange yellow shadows in Popups (e.g.Hover) Closing.
