Bug 117006 - On GNU/Linux, with High Contrast theme, the icon set is not correct
Summary: On GNU/Linux, with High Contrast theme, the icon set is not correct
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility
Depends on:
Blocks: High-Contrast Icon-Themes
  Show dependency treegraph
 
Reported: 2018-04-14 13:10 UTC by Alex ARNAUD
Modified: 2018-04-23 14:53 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex ARNAUD 2018-04-14 13:10:00 UTC
Description:
Hello all,

I'm visual-impaired, I'm using the High Contrast theme from GNOME with latest LibreOffice (version 6.0.3 from the Debian repository. When High Contrast theme is used on the system,  the LibreOffice Hight Contrast icon set should be selected.

Steps to Reproduce:
1. Install the GNOME Accessibility theme, available on package gnome-accessibility-themes on Debian/Ubuntu
2. Change your theme to High Contrast, on appearance on Mate, with GNOME Tweak on GNOME
3. Launch LibreOffice
4. Go to Tools, Options, View, on the icon style, check the automatic value

Actual Results:  
The automatic value should be High Contrast, not Tango (the default one)

Expected Results:
The High Contrast set should be selected


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Alex ARNAUD 2018-04-14 13:21:46 UTC
FYI, I'm on Elementary on the master branch.

Best regards,
Alex.
Comment 2 Heiko Tietze 2018-04-14 18:12:33 UTC
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 ***
Comment 3 Alex ARNAUD 2018-04-14 20:53:43 UTC
(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.
Comment 4 Alex ARNAUD 2018-04-20 12:54:40 UTC
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.
Comment 5 Heiko Tietze 2018-04-20 13:03:07 UTC
(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.
Comment 6 Alex ARNAUD 2018-04-20 13:05:41 UTC
(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.
Comment 7 Heiko Tietze 2018-04-20 14:50:24 UTC
(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.
Comment 8 Alex ARNAUD 2018-04-20 15:25:14 UTC
@Samuel: could you reproduce the issue?

Best regards,
Alex.
Comment 9 V Stuart Foote 2018-04-20 17:51:54 UTC
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.
Comment 10 Xisco Faulí 2018-04-23 13:16:54 UTC
Also reproduced in

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 11 Heiko Tietze 2018-04-23 14:02:42 UTC
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.
Comment 12 V Stuart Foote 2018-04-23 14:33:22 UTC
(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
Comment 13 Heiko Tietze 2018-04-23 14:53:10 UTC
(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;