Community
Participate
Working Groups
Created attachment 90201 [details] Preferred vs. Current high contrast toolbar Icons in eclipse are faded and pale in an attempt to meet accessibility guidelines for users with high-contrast color schemes, where icons in menus and toolbars are displayed on top of a black background. The results in this color scheme are anything but high-contrast for those users that actually need them to be. Yet, for everyone using default color schemes, most icons appear non-standard when compared to other familiar applications like Office. For example, paragraph alignment (left, center, right) is normally depicted with black lines. But in eclipse (or in products built on top of eclipse) some dark blue color is used instead because of accessibility concerns. Instead of this compromised approach, this problem should be solved programmatically, as it is in Office and similar products. ImageDescriptor should provide a getHighContrastDescriptor() method which returns an ImageDescriptor which inverts the *values* of the original descriptor's ImageData (while preserving hue/saturation). This new descriptor should be used by ActionContributionItem and similar classes whenever high contrast mode is enabled or detected. The attachment shows the many advantages for users who actually need high contrast. Disabled actions (as shown: Save, Print, Profile, Next and Previous Annotation) would appear as such. Circles would still be circles and not octagons (Run action). Dark shapes like "Bold" or the legs on the "Debug" bug would be white and really offer high-contrast. For the majority of users/products, this would mean that graphic artists could once again entertain the use of black, providing consistency with other native applications. At the same time, products could actually meet accessibility requirements, rather than just claiming to do so.
Maybe for 4.0...?
I like the idea of computing the high contrast ones (and leaving the graphic designers more breadth to work in).
sev = major?
(In reply to comment #3) > sev = major? Mostly for accessibility. If you look at the second row in the screenshot, I don't think you would say that that is satisfying the definition of high contrast. The only visible actions are the disabled ones.
Marking 3.5 for investigation purposes.
While I agree that it'd be good if this work happens, there's no resources to do it presently. Changing owner/QA contact as per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Created attachment 128225 [details] high contrast image descriptor The attachment provider an implementation of ImageDescriptor that provides a high-contrast (value-inverted) variant of some given "base" ImageDescriptor. I tried this out by adding to ImageDescriptor: public static ImageDescriptor createHighContrastVariant(ImageDescriptor desc) { if (desc == null) return null; return new HighContrastImageDescriptor(desc); } ... and modifying ActionContributionItem: private boolean updateImages(boolean forceImage) { ResourceManager parentResourceManager = JFaceResources.getResources(); boolean highContrast = isHighContrast(widget); ... ... ImageDescriptor image = action.getHoverImageDescriptor(); if (image == null) { image = action.getImageDescriptor(); } ImageDescriptor disabledImage = action .getDisabledImageDescriptor(); if (highContrast) { image = ImageDescriptor.createHighContrastVariant(image); disabledImage = ImageDescriptor.createHighContrastVariant(disabledImage); } ... ... // And so on, whenever images are applied to toolbars, menus, etc.
The utility method in ContributionItem (to be called eventually from CommandContributionItem and other places wanting to invert images) is: static boolean isHighContrast(Widget widget) { if (widget == null || !widget.getDisplay().getHighContrast()) return false; RGB rgb = widget.getDisplay().getSystemColor(SWT.COLOR_WIDGET_BACKGROUND).getRGB(); return rgb.red + rgb.green + rgb.blue < 20; }
Created attachment 128227 [details] Screenshot of eclipse 3.5 with patch applied
(In reply to comment #6) > While I agree that it'd be good if this work happens, there's no resources to > do it presently. Kevin, can you (or someone) comment on the approach used in the proposed patch? i.e., do you agree that consumers of ImageDescriptors should explicitly test the "environment" in which the Image will be placed and subsequently obtain the high-contrast variant for the Image? Here are some issues I see with this minimal patch: 1) There are still places that need to test and use high-contrast images, such as CommandContributionItem. 2) Black or dark toolbars still occur without Display#getHighContrast() returning true. true is only returned when gigantic fonts are also enabled using the accessibility control panel. 3) The "blackness test" simply asks SWT for the WIDGET_BACKGROUND color. Colors might not be reliable on OSes that rely on themes to render menus and toolbars. 4) The high-contrast variant imagedescriptor could be cached, even though it does implement equals() and hashcode() properly. 5) Doesn't update dynamically when the user changes system. Probably not a showstopper, since the workbench tells you to restart anyways. Lastly, I assume an API freeze is already in effect for 3.5?
Susan is now responsible for watching the [Graphics] category.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
