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.

Dear Alex ARNAUD,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug