Bug 167305 - Should not let "dark-mode-ness" of theme and of icon theme diverge implicitly
Summary: Should not let "dark-mode-ness" of theme and of icon theme diverge implicitly
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
26.2.0.0 alpha0+ master
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: UI-Theming Dark-Mode
  Show dependency treegraph
 
Reported: 2025-06-30 15:06 UTC by Eyal Rozenberg
Modified: 2025-06-30 17:38 UTC (History)
3 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 Eyal Rozenberg 2025-06-30 15:06:28 UTC
We have decided (at least for now) to not distinguish the light-vs-dark'ness of themes in the UI, and just have a single list of possible themes. Similarly, there is a single list of icon themes.

However - in practice, this can be quite problematic, especially for novice users. Suppose "Benjamin" is working on an LO installation which has the Colibre icon theme and the Light theme (it was installed that way or configured by whoever installed LibreOffice for him). He now decides he wants to try "Dark Mode", which he heard LibreOffice now supports, or remembers from the first-startup dialog. So, he goes to Tools > Options > LibreOffice > Appearance, and changes the theme to Dark. He does not see anything wrong; even if he does notice the icon theme, it just says "Colibre", not "Colire Light".

Closing the dialog - oh dear! The toolbar button images are now faded terribly into the background. Benjamin decides that LibreOffice is broken, or that he did something wrong, and just goes back to light mode.

Since we do not recognize the light-ness or dark-ness of a theme, nor of an icon theme, we cannot know that a theme change may require an icon theme change from the light variant to the dark variant.

Since I don't exactly what you (= people now working on theming and the Appearance dialog) are aiming for, it's difficult for me to offer an exact solution, but something needs to be done, I believe.
Comment 1 V Stuart Foote 2025-06-30 16:52:38 UTC
But we've two theming modes to track for icon theme handling: os/DE where Automatic reigns and Light / Dark override with some sense of Automatic. And that continues to work since 7.6 for bug 153497. But maybe gets muddled when a Light/Dark rb is selected.

And second, the newly revised single color sense theme framework for 25.8, configured by .xcu

IMHO yes it would be "appropriate" for the appearance themes .xcu to specify an icon theme (and fallback) to use with the appearance theme. Its come up a few times (bug 163420, bug 147086 and bug 148764). 

But the appearance theme framework does not include it currently, so needs some effort. Also we'd need to continue to specify default icon theme(s) for os/DE consumption as Automatic/Light/Dark.

While distro packagers remain free to select the default icon themes to support their Dark/Light modes.
Comment 2 Eyal Rozenberg 2025-06-30 17:03:44 UTC
(In reply to V Stuart Foote from comment #1)
> But we've two theming modes to track for icon theme handling: os/DE where
> Automatic reigns and Light / Dark override with some sense of Automatic. And
> that continues to work since 7.6 for bug 153497. But maybe gets muddled when
> a Light/Dark rb is selected.

The user doesn't know about that stuff. They only get to choose a Theme. Do you mean the "automatic" theme? That does not resolve the problem, since the icon theme is not "automatic". If you choose the "Automatic" theme and your icon theme is "Colibre", it remains Colibre light.


> While distro packagers remain free to select the default icon themes to
> support their Dark/Light modes.

So, do you support, when the user changes the theme, for us to force-change the icon theme to the theme's default? They would still be able to change the icon theme themselves of course.
Comment 3 V Stuart Foote 2025-06-30 17:38:33 UTC
(In reply to Eyal Rozenberg from comment #2)
> (In reply to V Stuart Foote from comment #1)
> > But we've two theming modes to track for icon theme handling: os/DE where
> > Automatic reigns and Light / Dark override with some sense of Automatic. And
> > that continues to work since 7.6 for bug 153497. But maybe gets muddled when
> > a Light/Dark rb is selected.
> 
> The user doesn't know about that stuff. They only get to choose a Theme. Do
> you mean the "automatic" theme? That does not resolve the problem, since the
> icon theme is not "automatic". If you choose the "Automatic" theme and your
> icon theme is "Colibre", it remains Colibre light.
> 
> 
> > While distro packagers remain free to select the default icon themes to
> > support their Dark/Light modes.
> 
> So, do you support, when the user changes the theme, for us to force-change
> the icon theme to the theme's default? They would still be able to change
> the icon theme themselves of course.

Yes. Automatic as on first launch with new profile, i.e. no Appearance theme selected and enabled, follow os/DE Dark/Light color sense and the TDF builds assign a default Icon theme, as devs or distro packagers decide. As its been since OOo era.

But now with the Appearance framework evolving, theme designers should have the ability to specify the icon theme along with the UI color theme when applied or take defaults of os/DE, and for users to make an alternate icon theme assignment. But defer to the theme designer choice for defaults for the theme.

Not to be confused with the Document color theme.