Created attachment 18383 [details]
screenshot of high contrast mode and relevant OO settings

SBA-> Wouter: OOo 1.0.2 is quite old. Please switch to a newer version (OOo
1.1.3 is available as well as OOo 2.0 cand. developer builds), verify your
findings and comment. Thank you.
Reassigned to ES.

Sorry. It's 1.1.2, which is much more recent. I don't know if 1.0.2 had any high
contrast mode already.

Anyway, the options in the configuration window don't see to do anything at all.

ES->MT: same thing on Windows. it has probably never worked....
When the option is OFF, OOo should come back to a normal non HC mode.
If not on the fly, at least after restart

MT->SSA: IMHO we can't detect HC on/off, because it's just a theme and we guess
depending on colors.

Not sure - who can have a look at that? (VCL)

ssa->pl: I'm not sure who evaluates the "Automatically detect high contrast mode
of operating system" setting, but at least the toolbar images (high contrast vs.
normal) are set by the framework.

This issue persists in the 2.0 branch, independent of the setting "Automatically
detect high contrast mode of operating system".

This is in Debian 'unstable' under Gnome. Curiously enough, OO doesn't go into
high contrast mode when run under KDE -- despite a similar, dark theme.

Toggling this setting has no effect at all. I wonder what the point of it is
then;  surely, the person(s) who implemented this function or any related
OS-specific code must have a clue about what's going on here.

see also issue 59364

However, what is the actual problem with the screenshot ? As far as i can see
OOo follows the theme (which is very dark) and the toolbars show the HC dark
icons (which they are supposed to do when the background color is very dark).

In general the highcontrast setting is not used very often over OOo's
application code and mostly in error.

On Windows systems the "high contrast" setting is just a checkbox which enables
a different set of themes. This setting is normally read from the system unless
you have enabled "Automatically detect high contrast mode of operating system",
in which case this setting is overridden by a guess based on the window
background color. On Unix systems the settings cannot be read from the system at
all since there is no such setting as "high contrast", HC is just another theme.
Here the "setting" is simulated by guessing - which happens to use the same
method as the "automatic" guess.

So i think there is no defect, but perhaps you expected something different to
happen by toggling "Automatically detect high contrast mode of operating system" ?

I believe the status in the screenshot _IS_ an error.  According to the ui spec
( http://ui.openoffice.org/specification/options_accessibility.html ):

7) Automatically detect high contrast mode of operating system

This option will be used by the function GetHighContrastMode (responsible
developer is Philipp Lohmann). If this option is active (default is on) the
internal function GetHighContrastMode determines a high contrast mode not only
by analyzing a maybe existing flag of the operating system. Then the function
will also determine if the window background is dark by using the IsDark
function and return true regardless if a high contrast flag is set or not.

Instead of asking for this single flag at the SvtAccessibilityOptions the
applications should use the above method
Application::GetSettings().GetStyleSettings().GetHighContrastMode().


The way I read this is that the system should only attempt to determine whether
the theme is a high contrast theme if this box is checked.  If this box is
unchecked, then OOo should not do any kind of theme checking and simply use
whatever the user-configured theme is.

Dark themes are becoming much more popular, especially with their default
inclusion in many popular distros.  Accessibility mode can make OOo virtually
_unusable_ for more advanced tasks, and there is NO way* to turn it off if
you're using a dark theme!  This makes this a _serious_ usability bug IMHO. 

*If there is, I haven't found it. Such a setting I would then consider FAR too
cryptic and generally a defect in usability.

*** Issue 70501 has been marked as a duplicate of this issue. ***

target

correct OS

fixed in CWS vcl101

please verify in CWS vcl101

Fixed but failed in vcl101.
Let's give an other CWS a try...

reassign

Is issue #82875 a duplicate? And issue #52511 and issue #87147 ?

I'm using KDE, and my kde themes are applied to gtk apps. It seems the threshold
is as follows:
OOo enters Contrast Mode when my system window background color is:
rgb: 38,38,38 or hsv: 0,0,38 (#262626)
rgb: 39,39,39 or hsv: 0,0,39 (#272727) disables that mode.

The Accessibility option "Automatically detect high contrast mode of operating
system" has no effect in any of the apps.

High Contrast Mode affects fill color on objects in impress as well as the
background color and borders of the cells in calc. Basically, all of the new
transparent selection stuff in 3.1.0 is disabled in this mode. In Writer I can
set background color on text, but not on objects (or at least, I can set it, but
it is not visible due to this mode).

A fix allowing me to use my dark themes in conjunction with open office, without
enabling the High Contrast Mode would be appreciated. Thanks!

ok, fixed but failed. The guessing part indeed is no more, but we finally have
OOo in the originally desired state where a dark background would result in the
high contrast "theme" everywhere it mattered (like in dialogs, toolbars,
virtually everywhere). And now we don't want that anymore I guess.

This will be more tricky than I expected. How awkward. It means that I and my
predecessors have told developers all those years "don't use the HC flag,
evaluate the background and see if it is dark". And now it will have to be the
other way around to make this work.

@cd: any input from the framework and toolbar point of view ?

Uhm, really?

That would be literally hundreds of places, where we would need to change the
"BackgroundColor.IsDark" heuristics. No fun at all.

I think that would be fine if the HC option were enabled by default. If someone
has a dark theme, they can disable it.

"Application::GetSettings().GetStyleSettings().GetHighContrastMode()" should
then be used in place of every current instance of "BackgroundColor.IsDark".
GetHighContrastMode() should check "BackgroundColor.IsDark" if and only if the
HC flag -- enabled by the "Automatically detect high contrast mode of operating
system" option -- is on. At this point, if BackgroundColor.IsDark returns below
the acceptable threshold, then is the OOo HC mode enabled by returning true from
GetHighContrastMode().

To save cycles, you might be able to just check BackgroundColor.IsDark once on
startup (and when the HC Flag changes) and set someother flag that
GetHighContrastMode() would use to check this.

Granted, I have not looked at the code base (and so maybe everything I've said
here is already clear and I didn't need to bother saying anything), but would
doing something like this work?:
sed -e
"s/BackgroundColor.IsDark/GetSettings().GetStyleSettings().GetHighContrastMode()/g"
*

Where would that not work? Why else would the BackgroundColor.IsDark be used
that is not an accessibility thing?

@fs: yes, no fun at all.
@techgurufloyd: yes, that's essentially the plan. Only there are some places
where IsDark is not asked for HC mode but to react on dark settings (e.g. not to
paint black text on black). So it's not completely automatic.

fixed in CWS changehc; unfortunately the whole review could not be done due to
missing resources, but most of the UI does not use the guessing mode for HC
anymore if switched off in tools->options. The benefit for dark themes justifies
not waiting for all places to be fixed and therfore delay integration.

See also followup task 104678 (target 3.3). That also will cover the current
problem that switching off the "autoguess HC" mode only gets active after restart.

please verify in CWS changehc

Verified in CWS changehc.

*** Issue 88084 has been marked as a duplicate of this issue. ***

This still seems to be coming up under 3.2.0. Only useful workaround so far is
to "export SAL_USE_VCLPLUGIN=gen" in .bashrc somewhere.

It seems like the document formats tend to assume white backgrounds as a
default. Eg, you can set the foreground color to a value you expect to be
visible, regardless of the system's configured background color. (partially ot,
but related). With this in mind, I'd expect the only useful behavior is to
ignore the system theme for document content, and only use the theme for
decorations/widgets that aren't part of the document.