Created attachment 32405 [details]
Fix for this issue.

I don't know why that code was exactly as it is now. Personally I think instead
of duplicating the autodetection as in your patch we should (?) remove the first

if( !rSettings.GetStyleSettings().GetHighContrastMode() )

But i'm really not sure how this is supposed to work in the first place. I'll
discuss this with ssa who if i'm not mistaken implemented this.

Created attachment 32439 [details]
Better version of the patch.

You are right, my patch was not the nicest.  I've mocked it up quite in a hurry
- sorry for that.

I think that the reason for the 'if' was that creating a service factory is
quite expensive IIRC; but it could be something completely different, of course
;-)  With the new patch, I ask for the status of the "AutoDetectSystemHC" just
when we should use HC mode according to the darkness of the windows.

The other thing was that it seems to me that OOo enters HighContrast mode
regardless of the 'View->Accessibility->Automaticall detect high contrast mode
of the operating system', but that's probably for another bugreport, right?

The HighContrast mode setting actually is set (or not) in the windows specific
part of vcl as on Window HC is an additional bool like state. This is of course
not the case on Unix desktops where HC is just another theme (which is probably
the better approach, but ...). This is by the way also one thing that your new
patch would clobber; it would set high contrast to false if face and window
color were not dark, even if the Windows system setting says it were indeed HC.

Moreover it would clobber the high contrast mode setting with the auto hc
setting; that's not quite correct. The AutoHC setting tells whether we should
use an autodetection. The autodection for HC is currently (WindowColor.IsDark()
|| FaceColor.IsDark()).

I talked to ssa and he agreed that we have to think a little more about a
correct solution. My first idea was scratching the first if in there; in case
AutoHC is set we should autodetect else leave the HC setting untouched.

Actually the best solution might be to remove the HC setting once and for all.
It is way more reliable to check on the background in use to see whether some HC
handling is necessary or not. This need not bee Face or Window color, but is
really the current background of any control that has to handle high contrast.
Most parts of the office HC code are implemented that way anyway, but there are
some places where the HC setting is still used.

ssa and I discussed this issue further and found out that this code actually
implements spec'ed behaviout (see
http://ui.openoffice.org/specification/options_accessibility.html ). Now this
spec is concerned with desktops (well, Windows really) that have a specific
"high contrast mode". What we should do is emulate this behaviour in
SalFrame::UpdateSettings - which will render the "AutoHC" setting useless on
Unix since it will be effectively always on.

So i'll change the UpdateSettings methods of gtk and kde plugin to do this
IsDark() test always, this way the "high contrast mode" boolean stays an
implementation detail of the platform and we still have the behaviour as spec'ed.

Sounds good, thank you very much! 

fixed in CWS vcl50

verified in CWS vcl50

fix is in 680m153, closing