Bug 127138 - gtk3/gtk4: Dark system themes don't automatically enable corresponding dark icon themes
Summary: gtk3/gtk4: Dark system themes don't automatically enable corresponding dark i...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.3.0.4 release
Hardware: All Linux (All)
: high normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0 target:7.0.0.1
Keywords: accessibility
: 133579 143302 153264 155906 156245 157090 (view as bug list)
Depends on: 148764
Blocks: GTK3 Icon-Themes-Code Linux-Dark-Mode
  Show dependency treegraph
 
Reported: 2019-08-24 13:15 UTC by komzpa
Modified: 2024-03-27 08:37 UTC (History)
16 users (show)

See Also:
Crash report or crash signature:


Attachments
libre-office-icons-dark-theme (379.15 KB, image/png)
2023-07-05 15:43 UTC, Wojtek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description komzpa 2019-08-24 13:15:11 UTC
Description:
I'm running libre office on KDE. My theme system is Breeze Dark. Libre Office catches the colors, but icons are still from the white theme, almost invisible on dark background. Changing icon in settings help, but requires to know it's changeable at all.

Steps to Reproduce:
1. Install Kubuntu with breeze dark
2. Open Libreoffice
3.

Actual Results:
See the icons black-on-dark-grey

Expected Results:
Icons are contrast to background


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 andreas_k 2019-09-02 13:59:27 UTC
if you use the Default icon theme, the theme should switch between breeze and breeze-dark depend on the color theme the user use.
Comment 2 komzpa 2019-09-04 12:07:23 UTC
I confirm. This switch to breeze-dark did not happen to me on Kubuntu 19.04.
Comment 3 Aaron O 2020-02-14 14:14:45 UTC
Ah, thanks. For anyone else looking, the icon theme can be changed in Options -> LibreOffice -> View -> Icon Style

I'd only tried changing the theme, didn't know this was available. Maybe changing to a dark icon theme could be done automatically in the future? I notice it doesn't have this issue on other desktops like XFCE.
Comment 4 Rizal Muttaqin 2020-02-23 11:37:05 UTC
If I remember it correctly, some years ago in Ubuntu GNOME 2 era (I'm not sure it was OpenOffice.org or LibreOffice) after setting up High Contrast theme, this office suite switch to Galaxy inverted version. We could try to see the code.
Comment 5 Timur 2020-04-01 07:03:50 UTC
*** Bug 129504 has been marked as a duplicate of this bug. ***
Comment 6 Mihkel Tõnnov 2020-06-12 11:44:44 UTC
*** Bug 133579 has been marked as a duplicate of this bug. ***
Comment 7 Commit Notification 2020-06-24 09:33:52 UTC
Igor Poboiko committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/584eba1fec6a47f4aae69afbdec7fc761bb68d29

tdf#127138: Fix detection of system icon theme with Qt5/KF5

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Commit Notification 2020-06-25 11:43:13 UTC
Igor Poboiko committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/fc957e1281f889a6e711c24d81eb65bba40265a8

tdf#127138: Fix detection of system icon theme with Qt5/KF5

It will be available in 7.0.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Timur 2020-07-12 15:13:25 UTC
*** Bug 134733 has been marked as a duplicate of this bug. ***
Comment 10 Víctor Lara 2020-07-12 20:35:30 UTC
I'm not sure if the 134733 bug is a duplicate of the 127138 (sorry if I'm wrong). If I understand, the bug 127138 is about the icons in LO (and it's solved in 7.0). In fact, I tested this in LO 7.0 (RC1) and when I change to breeze dark theme (Opensuse Tumbleweed) the icons looks like they should (white against dark background). But the fonts preview in the font name menu still illegible, the color of the displayed fonts (with preview, in Writer) is light grey and the color background is white ¿May be a Plasma problem? Thanks you all.
Comment 11 Timur 2020-07-24 16:18:09 UTC
*** Bug 135102 has been marked as a duplicate of this bug. ***
Comment 12 Timur 2022-10-04 13:05:50 UTC
*** Bug 143302 has been marked as a duplicate of this bug. ***
Comment 13 Jeff Fortin Tam 2023-02-03 15:25:08 UTC
Just to clarify the current state of things: in LibreOffice 7.5.0.3, when the icon theme is set to "Automatic" and the toolbars are set to "Standard", it now switches between the elementary icon theme (in light mode) and the Breeze Dark icon theme (in dark mode). However,

* It won't work if you have set an icon theme preference other than "Automatic", which is what the bug report here is about
* It won't work if you use anything other than the Standard toolbar (bug #127583)
Comment 14 Stéphane Guillou (stragu) 2023-03-10 13:04:21 UTC
*** Bug 153264 has been marked as a duplicate of this bug. ***
Comment 15 Stéphane Guillou (stragu) 2023-03-10 13:14:03 UTC
*** Bug 153618 has been marked as a duplicate of this bug. ***
Comment 16 Stéphane Guillou (stragu) 2023-03-10 13:44:35 UTC
Generalising the summary, as this bug now catches both KDE and GNOME reports.

Testing GNOME 3.36.8 + Wayland and a recent master build:

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 082d009b6a156faa74c9966b0dffc5fa6ce22287
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

For both Yaru and Adwaita dark themes (I had to use GNOME Tweaks to have access to both), I used the following steps:

1. Desktop Environment theme is set to Dark
2. Open LO: icon theme is Elementary (unsuitable)
3. Tools > Options > LibreOffice > View > Appearance, change to "Dark": icon theme changes to Breeze (dark) (suitable)
4. Set Appearance setting back to "System"
5. Back in Desktop Environment's theme settings, switch back and forth between Light and Dark: no effect on the icon theme in LO.

Tagging as accessibility issue as it makes many icons hard to see before discovering that one can manually switch to dark icon theme.
Comment 17 Adolfo Jayme Barrientos 2023-03-13 17:46:52 UTC
What’s the effect after commits 772328b386db4ab5a2b15e650610c31b34815c8c and e629abc924bd3589d98a85d361e94a55794861f1? (for 7.6.0/7.5.3)
Comment 18 Jeff Fortin Tam 2023-03-13 21:32:52 UTC
Guillaume, I'm not sure how you can test this properly with GNOME 3.36.x, because on the GNOME side, the freedesktop dark mode was only implemented in GNOME 42 and newer, in the spring of 2022. This is not really about using Adwaita-dark or Yaru-dark anymore, that's the old way (which was pretty much impossible for applications to deal with, and I can't imagine LibreOffice handling this cleanly either).

More details on how it works nowadays:
https://blogs.gnome.org/alexm/2021/10/04/dark-style-preference/<
https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/Dark-Style-Preference

Unless you're doing something _really_ special with your OS, you will need a much more recent OS to effectively test this (maybe in a VM or liveUSB or a spare computer or something).
Comment 19 Jeff Fortin Tam 2023-03-13 21:42:16 UTC
Also, while I'm at it, I'll reuse my thoughts I had posted on #153618, so that they are not lost:

The fact that the UI bothers the user with manually choosing from a long list of light or dark themes is nonsense from a UX standpoint in a world where themes are complete; ideally, to be approved for inclusion (and to remain) in LibreOffice from here on, icon themes should be required to have both light and dark variants; then the UI should hide this complexity from the user, by just letting the user pick "Automatic (%theme_name)" or picking a preferred complete icon theme (ex: "Breeze" or "Colibre") but not a specific icon theme subvariant (ex: no "Breeze" vs "Breeze Dark", only Breeze)... then the app would automatically pick the theme's light or dark icon theme variant depending on its UI light/dark theme state.

Apparently the "Elementary" icon theme in LibreOffice doesn't have a dark variant at the moment; in #153618 I also stated my personal opinion that the "Colibre" icon theme is universally suitable & usable (in terms of UX), and could be a much better default than "Elementary" on the GTK version for Linux, even though Colibre is the official LibreOffice icon theme used mainly on Windows. It's just _that good_, in my view.
Comment 20 Pyroxar 2023-05-07 12:45:17 UTC
Fedora 38:
LibreOffice: 7.5.2.2
Kernel: 6.2
Graphics Platform: Wayland

It works, but only with the default toolbar.

Kubuntu 23.04:
KDE Plasma Version: 5.27.4
KDE Frameworks Version: 5.103.0
QT Version: 5.15.8
Kernel: 6.2
Graphics Platform: X11
LibreOffice: 7.5.2.2

It works, probably only with the default toolbar.


Ubuntu 22.04:
LibreOffice: 7.3.7.2
Ubuntu package: 1:7.3.7-0ubuntu0.22.04.2
GNOME: 42.5
Graphics Platform: Wayland

The icons only change when the color is changing, and the theme (light/dark) is ignored. In my interpretation, the light/dark theme of LibreOffice doesn't work properly, and Ubuntu additionally uses a terrible hack where they always use the Yaru icon set on the default system color (orange), which looks good for the light theme but not so great for the dark theme.
Comment 21 Stéphane Guillou (stragu) 2023-05-09 09:55:30 UTC
Pyroxar, please don't update the Version field to more recent versions, as it's about the "earliest version known to be affected".
Comment 22 Wojtek 2023-07-05 15:43:02 UTC
Created attachment 188220 [details]
libre-office-icons-dark-theme

(In reply to Jeff Fortin Tam from comment #19)
> Also, while I'm at it, I'll reuse my thoughts I had posted on #153618, so
> that they are not lost:
> 
> The fact that the UI bothers the user with manually choosing from a long
> list of light or dark themes is nonsense from a UX standpoint in a world
> where themes are complete; ideally, to be approved for inclusion (and to
> remain) in LibreOffice from here on, icon themes should be required to have
> both light and dark variants; then the UI should hide this complexity from
> the user, by just letting the user pick "Automatic (%theme_name)" or picking
> a preferred complete icon theme (ex: "Breeze" or "Colibre") but not a
> specific icon theme subvariant (ex: no "Breeze" vs "Breeze Dark", only
> Breeze)... then the app would automatically pick the theme's light or dark
> icon theme variant depending on its UI light/dark theme state.

I think https://bugs.documentfoundation.org/show_bug.cgi?id=148764 is about this exactly (should be added as "related"?)

I think this one (#127138) is not only GNOME/KDE specific as I just ran into this problem on macOS - I set the OS to switch to dark theme in the evening/night and having Sifr icon set (I like minimal icons) I got a dark icons contours on almost black toolbar.
Comment 23 Stéphane Guillou (stragu) 2023-08-03 13:43:42 UTC
Still the same for me in recent master build:

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: eef0c5d4d45ba35acfb6d8f7551fe565ca4badaa
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Starting with GNOME's "dark" appearance:
- On LO's "System" mode, does not use a dark variant automatically, sticks to default Elementary.
- Changing LO to "Dark" does change the icon theme to Sifr (dark).
Comment 24 Buovjaga 2023-08-10 05:44:29 UTC
*** Bug 156245 has been marked as a duplicate of this bug. ***
Comment 25 Buovjaga 2023-08-11 14:37:34 UTC
*** Bug 155906 has been marked as a duplicate of this bug. ***
Comment 26 Stéphane Guillou (stragu) 2023-08-11 20:21:23 UTC
Raising the priority, given that there's 8 duplicates and it affects accessibility.
Comment 27 Buovjaga 2023-08-24 15:01:47 UTC
*** Bug 155906 has been marked as a duplicate of this bug. ***
Comment 28 Buovjaga 2023-09-04 15:57:54 UTC
*** Bug 157090 has been marked as a duplicate of this bug. ***
Comment 29 Stéphane Guillou (stragu) 2024-03-27 07:31:07 UTC
I am now using Ubuntu 22.04 + GNOME 42.9, and with GNOME 42's "proper" dark mode, the Automatic icon set does switch when changing the GNOME appearance mode between "Light" and "Dark" styles. (It uses Elementary and Sifr respectively.)

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 1344e6261a1d856c71eca1e0cc29215a586bf335
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

Which confirms what Jeff said in comment 18.
Tested both Wayland and x11.
Also works for the Tabbed interface now that bug 127583 is fixed.

So I think it's either "works for me" or "won't fix" for GNOME users (with the recommendation to update to GNOME 42 or above).
@Michael, do you think that's fair?
Comment 30 Michael Weghorn 2024-03-27 08:37:25 UTC
(In reply to Stéphane Guillou (stragu) from comment #29)
> I am now using Ubuntu 22.04 + GNOME 42.9, and with GNOME 42's "proper" dark
> mode, the Automatic icon set does switch when changing the GNOME appearance
> mode between "Light" and "Dark" styles. (It uses Elementary and Sifr
> respectively.)
> 
> Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
> Build ID: 1344e6261a1d856c71eca1e0cc29215a586bf335
> CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
> Locale: en-AU (en_AU.UTF-8); UI: en-US
> Calc: CL threaded
> 
> Which confirms what Jeff said in comment 18.
> Tested both Wayland and x11.
> Also works for the Tabbed interface now that bug 127583 is fixed.
> 
> So I think it's either "works for me" or "won't fix" for GNOME users (with
> the recommendation to update to GNOME 42 or above).
> @Michael, do you think that's fair?

Yes, that sounds fair to me, closing as WORKSFORME, as requiring the required GNOME-side implementation seems reasonable to me.