Bugzilla – Full Text Bug Listing
| Summary: | [preferences] java editor does not respect high contrast settings | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Amy Wu <for.work.things> | ||||||||||
| Component: | Text | Assignee: | Platform-Text-Inbox <platform-text-inbox> | ||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | daniel_megert, eclipse, eclipse, Karice_McIntyre, kpeter, Leo.Kuznetsov, lindawat, n.a.edgar, steven.wasleski, stori, tlafoon, Tod_Creasey, trang_tran | ||||||||||
| Version: | 2.0 | Keywords: | accessibility | ||||||||||
| Target Milestone: | 3.3 M7 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows 2000 | ||||||||||||
| Whiteboard: | |||||||||||||
| Bug Depends on: | 180935, 71819, 180941, 180942, 183036 | ||||||||||||
| Bug Blocks: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Amy Wu
Since the editor I work on is also having the same problem, I think it would be nice, programmatically, if there was a way to detect that the "high contrast" setting has been enabled and which color scheme is being used. There is currently no way to detect that the high contrast setting has been activated. Taken from ibm software accessibility website: During initialization and when processing WM_SYSCOLORCHANGE messages, determine the state of the high-contrast option. To check for high contrast, call the SystemParametersInfo function with the uiAction parameter set to SPI_GETHIGHCONTRAST and the uiParam parameter set to the size of the HIGHCONTRAST structure. If the value of the dwFlags member of the HIGHCONTRAST structure includes the HCF_HIGHCONTRASTON flag, the high-contrast option is enabled. The following code sample from the MSAA SDK shows how the Inspect Objects tool checks for high contrast: BOOL fHighContrast = FALSE; HIGHCONTRAST hc; hc.cbSize = sizeof( hc ); if( SystemParametersInfo( SPI_GETHIGHCONTRAST, sizeof( hc ), & hc, FALSE ) && ( hc.dwFlags & HCF_HIGHCONTRASTON ) ) fHighContrast = TRUE; For more information, see Enabling High Contrast on the Microsoft MSDN site. if high contrast setting cannot be detected, is there at least a way to tell the java editor to use the system setting's font colors? (I know you can use the system setting for font, but not font color) Perhaps a checkbox in the Syntax tab of the Java Editor preference that says "Use System Default" and when checked, all the foreground color settings will be disabled and the system setting will be used. From my HATS (WSSD plugin) tester.. this is an Accessibility compliance issue.
Defect Description:
The black X in the close buttons blend in with the black background
making it very difficult if not impossible to see.
Directions:
Go to control panel and open up Display
Go to appearence tab and select High contrast from color scheme
Apply this color scheme and open up hats
Notice that the entire HATS window has a White X in the upper right hand
corner to close the entire program
down, but the x to close the welcome to hats page is so well blended in with
the black background, it looks'
like it isnt even there.
This isnt just a HATS problem, The X's blend in for WSAD as well. The Welcome
page for WSAD has the same problem as the welcome
page for HATS.
Is this going to be corrected in Eclipse 2.1.1 and ultimately in WSSD?
Any updates on this issue with high contrast?? This is not just an editor issue but usable for all Eclipse UI. Moving to Platform UI for comment. Kim do you have any suggestions for this re: the new color support for 3.0 *** Bug 69476 has been marked as a duplicate of this bug. *** Any confirmation that this will be fixed in Eclipse 3.0?? There are no plans to address this for 3.0.1, as there is a workaround: the user can manually modify the colours used for editors in the Eclipse preferences. Kim, could you please investigate how the new-in-3.0 API Display.getHighContrast() (bug 51582) could be integrated into the themes system? Perhaps a theme could provide different colours when in high contrast mode. Note that the current API does not distinguish between high contrast black-on-white or white-on-black, so it may not be of much help to a theme. We may need to request new API from SWT. Ideally Eclipse would just come up with appropriate colours (and font sizes) when the user had specified high contrast in the system settings, regardless of which theme is selected. It would be interesting to look at how web browsers handle this, and if they make any changes to the default style sheet when in this mode. Created Bug 71819 to track theme support. *** Bug 75313 has been marked as a duplicate of this bug. *** *** Bug 85217 has been marked as a duplicate of this bug. *** We are in the process of updating the accessibility information for 3.1. Is this bug going to be fixed in 3.1? It sounds rather complicated to fix compared to some of the other accessibility issues we have. This could be solved by high contrast support in themes *** Bug 150535 has been marked as a duplicate of this bug. *** Kim, what is the status/target of this bug? This is not fixed. The problem is that the font still uses black color instead of white. Maybe this is related to bug 168405. NOTE: The size is correctly adjusted. In case useful: Since it is not possible to detect themes, using "LIST_FOREGROUND" for the text color will automatically change the color to white (or to whatever the theme uses) when the system is in high contrast mode. This seems to work for the text editor but not the Java editor. (In reply to comment #21) > This seems to work for the text editor but not the Java editor. In the Java Editor, is it possible to determine if the foreground color (its RGB) is lighter or darker than the background color? Or put another way, can you determine if there is a lack of disparity between the fore- and background colors? If you can read these values, you could set up rule for minimum difference between RGB color sets. If the difference does not meet the minimum, then invert the foreground color. >This seems to work for the text editor but not the Java editor. The Java editor overrides the font color with its own (from syntax coloring settings). We would like to use the font's foreground color but didn't find a way to do query the (foreground) color of the currently used font. Any ideas? >you could set up rule for minimum >difference between RGB color sets. If the difference does not meet the minimum, >then invert the foreground color. This would be a hack and eventually change the settings behind the back of the user. We need a way to get the system color chosen in the accessibility settings: the user doesn't want to see white color if he has e.g. chosen "Red, White and Blue (VGA)" scheme. *** Bug 180947 has been marked as a duplicate of this bug. *** Tod, I suggest we move this back to Platform Text and open a new bug for the foreground font color. *** Bug 180949 has been marked as a duplicate of this bug. *** Added Bug 180977 for this issue in SWT. However I am still unclear why chosing a system default color is not possible and why getting the font color is helpful. It is just a matter of matching complementary colors such as using LIST_FOREGROUND and LIST_BACKGROUND together. I'm tagging this with 3.4 with the hope of getting the blocking bugs fixed ;-) It would still be possible to make the font tied to the current theme and then extend the system theme so I think Sorry hit commit too fast It would still be possible to define your fonts and colors using the theme API and then extend the system default theme with your extra values. The downside to this is that you will have fonts showing in two preference pages but you will at least be able to respect high contrast. You mean the font color, right? The fonts are already centralized. Another issue are the colors for syntax coloring on Java > Editor > Syntax Coloring. How would that fit into the themes story? Yes the colours. I think the solution for you would be to centralize the colours the same way - even for the syntax colouring. I'm not sure why they should be different. You could either make the color non editable in your preference page and link it to the fonts and color page or just be able to handle the change from either place. This won't work well witht the preview. Created attachment 64060 [details]
Test plug-in
Here is an example plug-in that extends the Reduced Palette (previously System Default) theme without anything showing up in the preference page.
If you look at the code in ColorTestDialog we look up a constant in the current theme and if it isn't there we skip it. When you look in the preference page it is not there.
We could do the same thing with the JDT colors and not have it show up in the UI but use a lookup of the current theme to see if there is a value and initialize it that way.
Created attachment 64099 [details]
Patch
Here is a patch that sets up a reduced palette for all of the colors in editors and JDT.
We likely want to make some better choices in some places and I may have missed a couple of constants (there are a lot of them) but this should get you started and show you the pattern I used.
Tod, thanks for the patch - it looks quite promising but there are some concerns:
- it seems to create intermediate colors that won't get disposed
- the code assumes that preferences are initialized in the UI thread which is
not good - we had several bugs due to this in the early days. I just
re-verified this with a simple RCP where a button does
some code in a separate thread: the initializer is run in that thread and
hence the code fails with an NPE or illegal thread access. This is a pretty
common scenario. Here are some:
1) an RCP that uses some code (e.g. simply access preference) form the
editors plug-in in a non UI-thread
2) a plug-in that uses the search plug-in and starts a background search
before the editors plug-in is loaded
3) WTP if they have their own perspective that doesn't use a JDT part:
if then a search is started in the background it will load JDT UI in
a non-UI thread ==> boom
==> we could change the patch to only be active if executed in the UI thread
- the colors aren't switched if the theme is changed
Created attachment 64221 [details]
Updated patch
Removed the unneccessary references to the JFaceResources in my first patch
Great Tod - the latest patch removes the first two concerns. As discussed, we should correctly define the colors as the approach taken in the patch is discouraged (see Themes ext point doc). Besides that I'll have to find the best way to reload the preferences upon theme change. Since me moved this far we will add this for 3.3. Created attachment 64449 [details]
Patch with the defaults added
Added the default declarations as requested.
I have modified and enhanced the Platform Text portion of the patch so that it hot updates the defaults and also the open editors when a theme changes. JDT part to followw... I have not applied the semantic highlighting changes from the patch, instead I compute the theme key directly from the given preference key. Besides that I added hot update code as well and fixed some broken default colors and key names in the plugin.xml. Fixed in HEAD. Available in builds > I20070427-0800. Tbanks again Tod! verified in eclipse-SDK-3.4RC3 via wtp S-3.0RC4-20080605233411 java syntax color respects high contrast settings now |