FYI, I'm on Elementary on the master branch.

Best regards,
Alex.

Requested in bug 75398 and submitted yet not merged in https://gerrit.libreoffice.org/#/c/52772/ is the replacement of Hicontrast by Sifr. Let's wait for this.

*** This bug has been marked as a duplicate of bug 75398 ***

(In reply to Heiko Tietze from comment #2)
> Requested in bug 75398 and submitted yet not merged in
> https://gerrit.libreoffice.org/#/c/52772/ is the replacement of Hicontrast
> by Sifr. Let's wait for this.
> 
> *** This bug has been marked as a duplicate of bug 75398 ***

To be sure: do you mean your patch will detect the GNOME High Contrast theme and properly set the Sifr? On the current master branch, GNOME High Contrast Theme is not detected at all and the icon set is not changed at all with this theme, it's why I think it's not detected.

Best regards,
Alex.

Hello Heiko,

I could always reproduce the issue, even if with the dev build the Fri Apr 20 07:03:00 2018.

What is your settings to make this working?

Best regards,
Alex.

(In reply to Alex ARNAUD from comment #4)
> I could always reproduce the issue, even if with the dev build the Fri Apr
> 20 07:03:00 2018.
> 
> What is your settings to make this working?

Sorry, I have no idea how the detection of high contrast works so I cannot trigger it to test. What I did is to exchange the default icon theme from Hicontrast to Sifr. And hopefully haven't break anything else, so I'm "happey" that you don't get high contrast in any version. ;-)

Bottom-line: if there is no ticket, please file one.

(In reply to Heiko Tietze from comment #5)
> Bottom-line: if there is no ticket, please file one.

It should be the goal of this ticket. Could you confirm it if you reproduce this behavior?

Best regards,
Alex.

(In reply to Alex ARNAUD from comment #6)
> It should be the goal of this ticket. Could you confirm it if you reproduce
> this behavior?

As said, I have no idea how to enable high contrast mode on my system. Feel free to add me to any bug, and when it's about accessibility V Stuart Foote as well.

@Samuel: could you reproduce the issue?

Best regards,
Alex.

On a Fedora 27 64-bit vm with
Version: 6.1.0.0.alpha0+
Build ID: 66c02d16dd078613e754dcc775f366413fad13f0
CPU threads: 4; OS: Linux 4.14; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-04-20_09:08:39
Locale: en-US (en_US.UTF-8); Calc: group

From Settings -> Universal Access: toggling the Seeing: HighContrast mode is not causing LibreOffice to switch from Automatic (Elementary) to Sifr. Elementary Icon set remains active while LibreOffice responds to the rest of the theme.

On terminal receive an error with each attempt to toggle to HC mode...

(soffice:3599): Gtk-WARNING **: Unable to locate theme engine in module_path: "hcengine",

Over on Windows 10, the LibreOffice toggle to Sifr does occur when one of the HC modes is enabled HC White looks the best.

Also reproduced in

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

Was chatting with Alex on IRC and besides the bug with the auto detection it would be more clear what's going on when we introduce an option "[ ] High contrast mode" that is set via auto detection but allows users also to manually override.

(In reply to Heiko Tietze from comment #11)
> Was chatting with Alex on IRC and besides the bug with the auto detection it
> would be more clear what's going on when we introduce an option "[ ] High
> contrast mode" that is set via auto detection but allows users also to
> manually override.

But, isn't that already in Tools -> Options -> Accessibility [1]:

Options for High Contrast Appearance
check-box -- Automatically _detect high contrast mode of operating system

Or, add an additional control to force HC mode enabled/disabled regardless of the autodetect?

=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/cui/uiconfig/ui/optaccessibilitypage.ui#133

(In reply to V Stuart Foote from comment #12)
> But, isn't that already in Tools -> Options -> Accessibility [1]:

AFAIU, this option activates the automatic detection but not the result - with a limited usage in my opinion. For the users it's a big different if they just enable the automatic driving and close the eyes (system is always right and needs no control) or enable the mode that warns if unexpected things happens requiring interaction (system is mostly right but user has control over it).

From the technical POV the code might be

if (IsDetectionEnabled) doDetect();

while my suggestion requires some "sophisticated" internal storage

IsHiContrastSystem = doDetect();
if (!hasManuallySet) {
 doEnabled(IsHiContrastSystem) }
 else {
 doEnabled(UserSetting) };

onCheck():
hasManuallySet = true;
doEnable(!IsEnabled);
UserSetting=IsEnabled;

does someone can fix this bug?

(In reply to andreas_k from comment #14)
> does someone can fix this bug?

We adjusted the hardcoded use of Tango derived HighContrast theme on Windows to use Sifr for see also bug 75398. 

IIUC the other os/DE GNOME themes never picked that up and continue to draw from the DE theme colors for the UI.

Assume there is a theme flag designating an accessibility mode that should be read to toggle to one of the Sifr icon sets. If not, then some measure of intensity of the FACECOLOR or DARKSHADOWCOLOR compared to the background coming from the DE theme could be used to select the light or dark Sifr icons.

And, idealy, rather than the hardcoded use of light/dark Sifr--adopt some of Tomaž's work on https://cgit.freedesktop.org/libreoffice/core/commit/?id=78a4e9cb89830191e77c558759e845e5a15b9cc7 and recolor the Sifr icon bitmaps in response to DE.