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.
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.
(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.
(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.
(In reply to Eyal Rozenberg from comment #0) > 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. While this applies to themes it does not affect icons. IconThemeSelector::GetIconThemeForDesktopEnvironment(const OUString& desktopEnvironment, bool bPreferDarkIconTheme) is typically called with GetWindowColor().IsDark() meaning we calculate the automatic icon theme in respect to the theme. In a nutshell, I cannot confirm the issue (using the brightness-agnostic KJ icons myself).
(In reply to Heiko Tietze from comment #4) > While this applies to themes it does not affect icons. But: 1. We have a single list of icon themes, no separation of dark and light icon theme. 2. If the general theme is not identified as "Dark", then it is not possible to choose a Dark rather than Light icon theme. > IconThemeSelector::GetIconThemeForDesktopEnvironment(const OUString& > desktopEnvironment, bool bPreferDarkIconTheme) is typically called with > GetWindowColor().IsDark() meaning we calculate the automatic icon theme in > respect to the theme. Well, this doesn't square with app behavior, and the icon theme selection in the UI, where you have to manually indicate you want icons for a Dark theme.
(In reply to Eyal Rozenberg from comment #5) > 1. We have a single list of icon themes, no separation of dark and light > icon theme. We do have dark/light icon themes for all OS/DE. > 2. If the general theme is not identified as "Dark"... Again, we do calculate the darkness. If this is not working in some specific scenario please report STR.
(In reply to Heiko Tietze from comment #6) > (In reply to Eyal Rozenberg from comment #5) > > 1. We have a single list of icon themes, no separation of dark and light > > icon theme. > We do have dark/light icon themes for all OS/DE. > > > 2. If the general theme is not identified as "Dark"... > Again, we do calculate the darkness. If this is not working in some specific > scenario please report STR. Right, and we track the os/DE Light/Dark color sense just fine (though a few warts on applying as they are toggled, necessitating restart to get stable). But I think the ask here is that as appearance themes continue to evolve, they will require the additional framework for the theme designers to specify the icon theme to be associated with the theme. It would have been critical while the themes, at 25.2 release, had both light and dark sense. But now that they are back to monocolor, the icon theme should be a designer's choice. They might want Sifr for a Light sense theme, but Collibre Dark for a Dark sense theme.
I would second the option to add a default icon theme for the theme in the xcu file. This way the theme developer can choose a good icon theme to fit its theme, and if the user wants another icon theme, he can choose another one.
(In reply to Heiko Tietze from comment #6) > (In reply to Eyal Rozenberg from comment #5) > > 1. We have a single list of icon themes, no separation of dark and light > > icon theme. > We do have dark/light icon themes for all OS/DE. Your sentence does not contradict mine... > > 2. If the general theme is not identified as "Dark"... > Again, we do calculate the darkness. If this is not working in some specific > scenario please report STR. If we are able to tell whether a theme is light or dark (not the specific themes "Light" and "Dark", a very confusing choice of names BTW), then - as Stuart suggests, we should switch the icon theme selection to its light/dark equivalent. That is a minimum. A stronger ask would be to switch to the theme designer's preferred icon theme. I am ok with both alternatives; but the first one only requires a bit of coding on the dialog while the second one requires more people to do work; so perhaps it's better to start with the first alternative. Also, a confirmation would be nice.