Community
Participate
Working Groups
We need the ability to determine when a user's display is set to "High Contrast" mode. In Windows this is as simple as a call to SystemParametersInfo. Not sure how this is determined on Linux or OSX. Here is more info for the Window's method. http://msdn.microsoft.com/library/default.asp?url=/library/en- us/msaa/access_2oqa.asp
api request, moving to SN
Please consider for M8. This is needed for the Workbench and Lotus Workplace to respond properly to high contrast mode. Currently we have an accessibility bug since view titlebars do not respond.
A change notification would be nice too, but we could live with just the predicate.
Assigning to Chrix. Please investigate the other platforms. Thanks.
Accessibility related ? Moving to Car.
Fixed > 20040312 It is only implemented on Windows. I could not find anything like this on the other platforms. Billy?
GTK+ has the concept of themes. Bill Haneman from Sun maintains a high contrast theme which ships with Gtk. While you may be able to do something based on the name of the current theme, possibly using the resource file API, this does not seem like the correct solution. The real bug is that SWT widgets are not honouring the active theme settings. A good example of a bug caused by this is bug 17563. There are other glaring issues visible on theme changes, such as background pixmaps for widgets. https://bugs.eclipse.org/bugs/show_bug.cgi?id=17563 http://developer.gnome.org/doc/API/2.0/gtk/gtk-Resource-Files.html
The real problem is that Eclipse is setting colors that override the Theme Manager. GTK does not have the concept of "High Contrast". Instead, users choose from a list of well named themes (ie. "High Contrast", "Large Print"). A well behaved GTK app should not be overriding the theme colors and fonts. If they don't do this, they will get the correct "High Contrast". I propose that this API be removed because it cannot be honoured anywhere but on Windows. Matthew? Speak up. Why do you need this thing?
Our Apps are not well behaved but the need to comply with IBM's accessibility standards. Thus if a user is running in "high contrast" mode, we do not want to override any fonts or colors. If the user is running in any other mode, we want control over SOME of the colors and fonts used in our custom widgets. This is critical for us, at least for the platforms that support it. I find it hard to believe that WMs like Gnome or KDE have no concept of "high contrast" mode. But I've been wrong before, haven't I <g>. Also note that high contrast modes on Win32 are defined via themes. If it's true that there's no such thing as "high contrast" on Linux or some other platforms, what's the harm in keeping the API and just returning false in these cases? You can be sure that Linux will have this support in the near future. -m@
Seems like a reasonable use to me. On GTK you will always be overriding fonts and colors when you shouldn't. Other than looking for well known theme names, I don't see how the API can be implemented anywhere but Windows. I see on the "Accessibility Options" dialog that there a bunch of high contrast themes available. Can these be chosen without setting "High Contrast" mode? If so, Windows can have the exact same problem as GTK. Adding Tod for his 2 cents. What is Eclipse 3.0 going to do?
Matthew, the GNOME accessibility people seem to have decided on the theme system exclusively for these modes. The accessibility guidelines specifically mention avoiding a dependency on specific high contrast modes: http://developer.gnome.org/projects/gap/guide/gad/gad-ui-guidelines.html One reason for this is the ability to support many different high contrast themes (High/Low Contrast, Large/Normal print, inverse of both). So, I don't see a clear reason why you would ever want a global "high contrast" setting. I think the intention is that applications adapt their colours to follow the current theme appropriately, or make colours configurable internally.
It seems that the right GTK way to do it if you insist on providing your own colors and fonts over and above the ones available from the Theme Manager is to go ahead and do so but allow the user to change these colors and fonts as part of your application. The disabled user is then supposed to navigate your application and reset everything. Is that right?
> allow the user to change these colors and fonts as part of your application. No, we would not allow the user to change the colors > The disabled user is then supposed to navigate your application and reset everything. Is that right? No, we were hoping to somehow detect (with Display.isHighContrast()) that the user is in a disabled mode and switch to using system colors. This would likely be driven by the Workbench Themes feature. The custom color theme would be defined with specific RGB strings, the disabled theme would be defined with system color directives (I believe this is possible with the current Themes implementation). I believe the above should apply to both win32 and GTK. We are open to using internals for this one. I can understand not wanting to commit to an API when some feature is only supported on one platform. If you go the internal way, can you give is a way to detect which theme is being used on GTK. -m@
All that GTK and the other platforms give you are themes that the disabled user can choose. These themes have arbitrary names. Because of this, there is no way an application that wants to use it's own colors and fonts can be smart on any platform other than Windows and detect that the user is visually disabled. It can't be done. Billy, do you concur? Given this, I am tempted to pull the API for now and give you a Windows only solution. Alternately, we can leave the API we have. It seems that whatever we do, your app will come up by default with bad colors and fonts for a visually disabled user on any platform other than Windows.
There is more to it than a "mode" as well. I can easily emulate High Contrast settings by playing with other parameters (like my font size and colours) on windows. I would just as soon have a preference in the Eclipse workbench that tries to make the right decision by querying SystemParametersInfo on Windows and can be set by the user in the UI. A user who needs High Contrast would much rather have a setting that they can enable and have work then a half solution that does it for them. Look at XP - it give you a mode to set which sets the flag you mention below.
I'm closing this as FIXED. Display.getHighContrast() is a hint that allows programs on Windows to get the right defaults for a visually impared user.
Not sure if I should have created a new bugzilla report? We need the ability to detect changes in the highContrast setting. Currently SWT does not provide any notification of such change. Without this notification, custom widgets cannot draw properly. Consider the following use case: An instance of Eclipse is shared by two users. One of the users is visually impaired and one is not. The user that is not visually impaired has written some code in Eclipse and needs the user that is visually impaired to review it before it is committed. The visually impaired user now needs to use Eclipse on this machine in high contrast mode, without having to restart Eclipse.
There is a work around (close and restart Eclipse). In any case, this bug report says "Need the ability to determine "High Contrast" mode, and this problem has been implemented. Please create a new problem report. Thanks.
Before it was reopened, this was marked as RESOLVED FIXED.
Re-closing.
See bug 71482 for the enhancement request in comment #17.
