Community
Participate
Working Groups
I like black backgrounds. I've changed my editor accordingly. However, the declaration view shows a light yellow background. Colors that show up well on black do not show up on light yellow. This general assumption throughout JDT that the background for java code should be colorized against and arbitrary background is a consistent reocurring issue. It's been a problem in diff viewers, various "popups" (and other places, I think). They should either: a) use the editor background b) not colorize the java code or c) let me set a background color for that usage explicitly. In the case of Declaration view, I can certainly see the advantage in having the background NOT be the the same as the editor, so let me set that in the preferences.
I20030820 You can set it: it is the same as in the tool tip text of your platform i.e. you probably "experience" the same problem when using the source hover (Ctrl+hover) to look at source. I agree that combining color preferences from Eclipse with global platform preferences for one view is not optimal.
How is the platform color set for Linux-GTK? (I'm running KDE if that matters...)
I heard that there are files which control the UI. I'm not a Linux expert. I suggest to ask on a Linux newsgroup.
Should I submit seperate bugs for EACH place in Eclipse that has "color mismatches" like this, or should I just add to an existing one? (The latest is in the breakpoint properties dialog, where the "condition" text area is always a white background (or so it seems) yet uses syntax-colored Java.)
Please file a bug for each one since the components might differ.
*** Bug 45900 has been marked as a duplicate of this bug. ***
*** Bug 50167 has been marked as a duplicate of this bug. ***
*** Bug 51587 has been marked as a duplicate of this bug. ***
*** Bug 58941 has been marked as a duplicate of this bug. ***
*** Bug 60467 has been marked as a duplicate of this bug. ***
Since the Declaration view is not a Tooltip, why does it use that color instead of the default application background color?
The idea behind this was that we wanted to make it more similar to the hovers.
For the tooltips which use editor syntax colors for foreground, why not use the editor background as well?
Is it possible for this to be resolved by 3.0?
*** Bug 65612 has been marked as a duplicate of this bug. ***
*** Bug 68900 has been marked as a duplicate of this bug. ***
*** Bug 65754 has been marked as a duplicate of this bug. ***
*** Bug 68700 has been marked as a duplicate of this bug. ***
*** Bug 70859 has been marked as a duplicate of this bug. ***
*** Bug 38818 has been marked as a duplicate of this bug. ***
*** Bug 79947 has been marked as a duplicate of this bug. ***
*** Bug 88616 has been marked as a duplicate of this bug. ***
Deferred.
IMO, this should NOT be filed as "enhancement". This is a bug, plain and simple. Reasonable settings (i.e. light text on dark in editors) render whole features unusable. I personally *like* using dark backgrounds, but for many people with eye-strain or other problems, they're an absolute necessity. This makes this a blatant accessibility violation. Anything that colors syntax should use the editor background, period. (Using the tooltip color if the background color has been left at the default is a reasonable special case.)
*** Bug 97747 has been marked as a duplicate of this bug. ***
*** Bug 109864 has been marked as a duplicate of this bug. ***
Created attachment 31916 [details] Patch against 3.1.1 for coloring of code tooltips Attached is a first effort at fixing one of the issues covered in this bug - that of tooltips being miscolored (as opposed to code in properties dialogs; I haven't looked at that yet). A few issues that came up as I slapped this together: 1. So I added a new preference to the place where it seemed most natural, the list of colors under Preferences->Java->Editor. However, there's a problem in that the default should really be whatever the default tooltip color is for the system, and the mechanism for the color preferences doesn't seem to allow a "none" or similar for a fallback. (The kludge I've employed is to hardcode my GTK theme's tooltip color as the default. It looks fine to me :-) ) 2. With a different background color, the tooltip suddenly doesn't look like a tooltip (yay for conditioned visual cues), so I put in an inner border with the standard tooltip color. To my eye, it now still looks plenty tooltippy. 3. I added a pixel's worth of padding to the code area, in the tooltip background color, to make it rather less cramped-looking. (This does change the appearance even with the default settings; however, I think it looks better, and at any rate more like a pure-text tooltip than before.) I haven't any idea how sane this patch is; I'm very new to the Eclipse source base, so likely I stepped on a few delicate things ... (BTW, I recall that on the docket for 3.2 are some improvements to handling of color settings, such as color schemes and whatnot - has that gelled enough that I should try and redo this patch for HEAD?)
After reading comment #1, I can see how the current implementation makes sense. As I understand it, the general goal is for Eclipse to use system preferences whenever possible and be a good UI citizen, as it were. In the light of this, making the various pop-ups use the system "Tool-Tip" color makes perfect sense and *should* work prefectly well. This also that means people like me - who use a dark background for code editing, but use the typical black-on-white system settings everywhere else - are causing trouble for everyone else :) Catering to our inconsistent preferences would require Eclipse to "detach" itself from the system preferences. From a consistency point of view, it is objectively the case that this makes things a bit more complicated. But I still want it :)
Actually, this problem comes from the fact that Eclipse is NOT using the system preferences. Eclipse is using the system preference for the tooltip background color, but not the foreground color. I agree that for those who use dark-on-light the current implementation is easier to read then the system preference would be, but whenever a UI goes against the system preference there needs to be an option somewhere that allows a user to at the very least revert back to the system preferences. I have no problem with dark-on-light tooltips that are monochromatic (instead of syntax highlighting) for my case. Just give me the option to do it!
Hmmm ... The consistency argument is well-taken, but I'm not sure it applies here. Consistency also demands that we color text in the system text colors (i.e. usually black on white), and this is the default. But as soon as the user overrides the system preferences, we must also respect coherence *within the application*. Light text on a light-colored tooltip is incoherent, so if we let the user tweak the text color, coherence demands that we let him change the tooltip color to match. It's true, giving an option to turn off highlighting for tooltips would fix the immediate issue, but it may complicate the code, and furthermore I hesitate to add a preference that smells like "make it work" (I'm an acolyte of Havoc Pennington of GNOME [1]). If we're burdening the user and the developers with yet another preference, I say we fix the problem, not back out. --- [1] See "The Question of Preferences" in http://ometer.com/free-software-ui.html for Havoc's rant about preference sprawl.
Created attachment 32040 [details] Improved patch, against 3.2M4 New version, now diffed against 3.2M4 (though it may well still apply cleanly to 3.1.1). Fixed graphical oddities when a status line is drawn.
Hi Luke, thanks for the patch it's a good start. After looking at the patch and re-reading the PR again I think we should start providing only one new color for setting the hover/tooltip background color and change the places in Platform Text (hovers) and JDT Text (hovers, quick and info views) to use this color preference instead of SWT.COLOR_INFO_FOREGROUND. Since the editor background is on the General > Editors > Text Editors preference page and hovers also apply to non-Java editors we should put the preference there, see TextEditorDefaultsPreferencePage and AbstractDecoratedTextEditorPreferenceConstants. Some additional comments to the patch: - please do not modify the project name because it makes it impossible to apply the patch to 'org.eclipse.jdt.ui' as a whole - it should not contain more than what's reported in this bug i.e. it should not modify the SourceViewiewerInformationControl (except for using the new color)
What about the non-code hovers, like the JavaDoc tooltips? Those aren't syntax-highlighted, so they're colored in black, and if they get the same (in my case, dark) background, they'll have the same problem code hovers have now. Does this concept of a "code hover", that is, one that shows highlighted source code, as opposed to, say, a "text hover" which does not, exist in the higher levels of abstraction? If so, it would be simple (I would imagine) to say "text hovers get standard tooltip colors and code hovers get highlighting and the custom background" in the code.
Other editors (e.g. Ant, CDT,...) also have "code" hovers and would need to duplicate the preference and I don't like different bg colors for hovers. When adding the bg preference we should also allow to set the (default) fg color for hovers. Both will default to the tooltip system colors i.e. there has to be the "System Default" checkbox.
Why would other editors have to duplicate the preference? Couldn't it just be made a general preference for all editors? Or maybe foreground and background colors for tooltips could be added to the Colors and Fonts preference page?
>Why would other editors have to duplicate the preference? Couldn't it just be >made a general preference for all editors? That's exactly my suggestion: don't introduce a preference in JDT but for all text editors. But you can't call it "code ..." since Platform Text doesn't know anything about code, Java, etc. >Or maybe foreground and background >colors for tooltips could be added to the Colors and Fonts preference page? Up to now we don't use those for Text and Java editor preferences for various reasons (no system default, can't specify not to use a corresponding color/font (i.e. disabel), ...). Currently we want to stay with the existing pattern.
I've added background color preferences for the Declaration and the Javadoc view. Hover background will come in 3.3.
Wait, do you mean there will be two new preferences, one for the declaration view and one for the JavaDoc view? Why? Why not just use the editor background for both? (It gets awfully tiresome to set the same setting in several different places ...) And why defer the hover background fix until 3.3? It's not exactly an earth-shatteringly complex fix ...
It's been a very long time since I participated in the background color(s) defect debate/process. I was one of the original reporters a couple of years back. At any rate, I've been very dissapointed in the way the color preferences have changed over the last few releases. Having color preferences distributed between the platform text editor prefs and the JDT syntax color prefs is just weird. In addition, unifying all text editor prefs may not be ideal. I'd like to bring to your attention my favorite approach, implemented in a nifty text editor called TextPad (www.textpad.com). In their preferences, there's a "document class" concept with an associated range of preferences, from language grammars and associated syntax coloring to encoding, file extensions, etc. What I find particularly nice about this is that they have a "Default" document class that is equivalent to a super-type that defines preferences for any and all document classes that have not specified their own set. The other nice aspect of this is that these very same preferences are repeated within each document class. The net result is that users are given the option of overriding preferences on a document class basis while still beign able to manage default settings that are shared by all non-overriden document class editors. Without knowing anything about the underlying code, it seems like a model that could be extended to Eclipse. The default document class settings would be in the platform prefs area, whereas each project would also present the same set of preferences as a means to override defaults for project-specific editors. Anyway, I really like Eclipse a lot, so I wanted to pitch in with some ideas for how to make it even better.
Yes, everyone can now freely choose. It won't be linked to your OS hover bg color, not to the OS default bg color and not to the editor bg color - full freedom for everyone. As for the hover color, it is not a hard fix but will have to go into Platform Text and will have to be exposed as API. Beyond the fact that we are beyond API freeze point we want to give other hover owners time to adopt this color in order to give a consistent look and feel.
Are there any plans to schedule a fix for this any time soon? I too use light text on a dark background, and having all my Eclipse tooltips get displayed as illegible light text on a bright yellow background is a huge nuisance. If there was some way for me to change either one of the Eclipse tooltip colors - either background or foreground - it would solve the problem. But the status quo is really awful. Anyone have any progress update on this?
It will be in 3.3 if time permitts.
May I ask what's keeping this up? Why does adding a preference require an API change pesky enough that a serious accessibility bug should be three years old? If changes like "make code hover background colors changeable" require this ungodly much time to fix, doesn't it seem that refactoring the entire text platform/preferences system might actually be *faster*? (And having the other day set roughly 15 different sets of syntax-highlighting settings to my liking, each with a different interface and many of them incompatible (no italics, etc.), I can tell you there must have been many, many more man-hours spent changing redundant settings than it would take to implement a text editing abstraction layer that WORKS.)
I can't wait to see your first patch doing this. Besides that you could also provide a patch just solving this problem or provide a better solution to set the syntax coloring preference - it's an open source project after all, isn't it.
Erm, if by "this" you mean refactor the text editing platform - well, you got me. But if you mean fix this bug ... see comment #27. (BTW, my experience with this bug is a large part of the reason I *haven't* contributed more to the Eclipse project. The fact that an accessibility bug with a simple fix has gone unfixed for over three years - including almost eight months since a patch was submitted - is discouraging to say the least. This is the sort of frustration that leads to forking, and nobody wants things to go in that direction.)
Please - as you know yourself the patch was not ignored, I reviewed and commented on it and after that no update was provided.
Created attachment 51928 [details] Screen shot of reversed colors (light text on dark background) setting on my OS
(In reply to comment #32) > Hi Luke, thanks for the patch it's a good start. After looking at the patch and > re-reading the PR again I think we should start providing only one new color > for setting the hover/tooltip background color and change the places in > Platform Text (hovers) and JDT Text (hovers, quick and info views) to use this > color preference instead of SWT.COLOR_INFO_FOREGROUND. Hmmm .... Well, if I understand correctly how you're proposing to fix this, I don't think it's the right approach. Let's take specifics. I have my color preferences set (both in Eclipse and on my OS) for light text on a dark background. (Specifically, light grey on dark blue - see screen shot at http://bugs.eclipse.org/bugs/attachment.cgi?id=51928) My problem occurs with the Eclipse tooltips because it's trying to display light grey on light yellow. Now to me, the correct solution would be to have a setting in Eclipse where I could change this to black on light yellow. (Exactly like Mozilla is doing in the location bar in the screen shot at http://bugs.eclipse.org/bugs/attachment.cgi?id=51928) However, that doesn't sound like the solution you're proposing here. It sounds to me like you're suggesting a setting that lets me change the tooltip background, i.e., the light yellow. While yes that would work, that doesn't really seem like the right solution to me. Yes, it would be functionally OK if I could make my tooltips light grey text on dark blue or such. But what would be a much more correct solution from a visual perspective is to have the tooltip be black on light yellow. And what that would require is a new setting to change the tooltip *fore*ground, not background. Thoughts?
Or, perhaps a more simple solution: Since Eclipse is hard-coding the tooltip background as yellow, then perhaps it should similarly hard-code the tooltip foreground as black instead of inheriting that text color from the OS. That's what Mozilla Firefox appears to be doing. Even though I've overridden my foreground and background colors to light grey on dark blue, Mozilla ignores those settings when displaying tooltips and just shows them as black on yellow. Perhaps Eclipse is trying to be a bit too clever here by taking into account the OS's text settings. If it simply ignored that text setting there wouldn't be any problem here.
I'm not sure what you're talking about now. Note that there are many different hovers, and for example the Javadoc hovers do use the system default foreground and the system default background. The problem described here is mainly applying to the source/code hover where we use the foreground settings from the Java editor. Are you suggesting to remove that functionality and display the source in the tool tip plain black?
Created attachment 51938 [details] Screen shot of tool tip color problem
(In reply to comment #50) > I'm not sure what you're talking about now. Note that there are many different > hovers, and for example the Javadoc hovers do use the system default foreground > and the system default background. The problem described here is mainly > applying to the source/code hover where we use the foreground settings from the > Java editor. Are you suggesting to remove that functionality and display the > source in the tool tip plain black? No, I'm referring to tooltips over the widgets in the Eclipse toolbar(s) (and possibly occurring elsewhere in Eclipse as well). See the tooltip at the top of this picture for an example: https://bugs.eclipse.org/bugs/attachment.cgi?id=51938 The text in the tooltip is unreadable because it's a light foreground color on a yellow background. What I'm suggesting is either: a) have Eclipse always use black on a yellow background for tooltips like this, or b) provide a setting to allow me to change the foreground color
>No, I'm referring to tooltips over the widgets in the Eclipse toolbar(s) (and >possibly occurring elsewhere in Eclipse as well). OK, then you are wrong here. Please file a bug report against Platform UI. This bug is about the custom tool tips provided by JDT Text (appearing when hovering over text in an editor).
Sigh
(In response to Comment #48) I think the right approach is to allow me specify a tooltip background color when you are using Java syntax coloring. The bug is to use text settings from the java editor and background from the operating system. The suggestion that both come from the operating system makes it usable, but you loose some 'power' in not having syntax highlighting available.
I agree with comment #53 - when it comes to source code tooltips, we need a background setting, not a foreground setting. I agree with commeent #55 - the reason we don't want to set the foreground color is because we want the foreground colors chosen according to syntax. I can understand why darose would be confused (in comment #48 and later) because the source code tooltips and the "help" tooltips suffer the same problem - even though they are generated by different code. I hope he will have success in getting these different kinds of tooltips disambiguated and getting different settings for each.
In my opinion there's no need for separate background setting for code tooltips. As the foreground colors are taken from the Java editor syntax coloring so the background should be likewise as it is in the editor.
(In reply to comment #57) > In my opinion there's no need for separate background setting for code > tooltips. As the foreground colors are taken from the Java editor syntax > coloring so the background should be likewise as it is in the editor. I see your point, but I think it's pretty fundamental to tooltips that they have a different background color than the content over which they appear. Don't you agree? For example, if your background color is black, and your tooltip background color is also black, that will make the tooltip sort of merge into the content that it overlays - it will look like a rendering mistake rather than a "pop up".
(In reply to comment #53) > OK, then you are wrong here. Please file a bug report against Platform UI. This > bug is about the custom tool tips provided by JDT Text (appearing when hovering > over text in an editor). Done: http://bugs.eclipse.org/bugs/show_bug.cgi?id=160879
(In reply to comment #46) > Please - as you know yourself the patch was not ignored, I reviewed and > commented on it and after that no update was provided. Fair enough. The frustration I refer to is procedural and organizational, not personal (though I know I tend to make things sound more personal than I mean to; sorry about that). Let me be specific. As I recall, it's comment #40 that I found particularly discouraging: > As for the hover color, it is not a hard fix but will have to go into Platform > Text and will have to be exposed as API. Beyond the fact that we are beyond > API freeze point we want to give other hover owners time to adopt this > color in order to give a consistent look and feel. Perhaps I misunderstand, but the image I get from reading this is of a slow, clumsy government bureaucracy. For good, idealistic reasons (fixing this at the platform level is the Right Thing; it's also an API change, and API freezes must be respected; consistency of UI is important), the quick, simple and effective solution to a problem is dismissed in favor of one that will be held up in committee for months (years?). This bug could have been fixed in 3.2. Yes, the already hideous preferences window would get marginally hideouser, but features which were worthless for many people could be made useful again; we would have saved the (important) goal of moving more functionality to the platform layer for another day. When I realized I'd found a bug that I cared about that I might be able to tackle, I got a charge out of it - enough to dive into the Eclipse code base (daunting, to say the least) and do it, and submit a patch. I then found that my simple change would have to wait months and months to be implemented, and only then if I mastered an enormous, labyrinthine API well enough to make a high-level extension. The ensuing buzzkill was not merely my wounded pride, it was a realization that even small changes like "let the user change the background color of Java code tooltips" would require a lot of hard work, both architectural and political. I didn't have the time and energy for the coding, or the patience for committee politics. I'd like to think this was an isolated case, but given the fact that syntax coloring (or at least the preferences for it) is reimplemented from scratch by so many different editors and has been for a long time, and that the user experience in the Preferences window is an absolute abomination and yet successive development plans never address this issue (at least not in plain English), I can only conclude that either Eclipse development really is as bureaucratic and sluggish as it appears, or it's hopelessly lost in groupthink and feature creep. Either way, the notion of investing myself as a contributor is less than tempting.
PMC request has been filed in order to fix this for M6.
+1
Fixed in HEAD. Available in builds >= I20070319-1800.
Verified in I20070320-0010.
As far as I understand this thread, it should be now possible to change the declaration view background color in Eclipse Europa? But how can I do it? I didn't find such a setting in the preferences dialog box. I only found Java->Editor->Source hover background, which doesn't affect the declaration view (it's still default gray).
(In reply to comment #65) > As far as I understand this thread, it should be now possible to change the > declaration view background color in Eclipse Europa? But how can I do it? I > didn't find such a setting in the preferences dialog box. I only found > Java->Editor->Source hover background, which doesn't affect the declaration > view (it's still default gray). > The General->Appearance->Colors and Fonts page contains an item under Java called "Declaration view background". I believe this is the one you're looking for.
(In reply to comment #66) > (In reply to comment #65) > > As far as I understand this thread, it should be now possible to change the > > declaration view background color in Eclipse Europa? But how can I do it? I > > didn't find such a setting in the preferences dialog box. I only found > > Java->Editor->Source hover background, which doesn't affect the declaration > > view (it's still default gray). > > > > The General->Appearance->Colors and Fonts page contains an item under Java > called "Declaration view background". I believe this is the one you're looking > for. This does not work on C/C++ editors (or any other non Java editors for that matter). This preference should either be duplicated on the "Basic" section of the General/Appearance/Colors and Fonts settings (or at the very least on the "C/C++ tab"). Since the original bug refered to JDT this bug seems to be fixed, but the fix is partial in the sense that this also affects all other editors.
(In reply to comment #67) > (In reply to comment #66) > > (In reply to comment #65) > > > As far as I understand this thread, it should be now possible to change the > > > declaration view background color in Eclipse Europa? But how can I do it? I > > > didn't find such a setting in the preferences dialog box. I only found > > > Java->Editor->Source hover background, which doesn't affect the declaration > > > view (it's still default gray). > > > > > > > The General->Appearance->Colors and Fonts page contains an item under Java > > called "Declaration view background". I believe this is the one you're looking > > for. > > This does not work on C/C++ editors (or any other non Java editors for that > matter). > > This preference should either be duplicated on the "Basic" section of the > General/Appearance/Colors and Fonts settings (or at the very least on the > "C/C++ tab"). > > Since the original bug refered to JDT this bug seems to be fixed, but the fix > is partial in the sense that this also affects all other editors. I agree, this should apply to a general section. Not Java one. I makes the option only available if the editor has implemented it.
