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.
I recently faced the same issue as "Benjamin" from Eyals very first comment and thought LibreOffice might have a bug, which is how I ended up here. What I was wondering is why only the dark themed icons have an additional description in their name, which the light themed once seem to lack. One example would be the icon theme "Sifr" where the dark themed variant is called "Skir (dark)" whereas the light one is called "Sifr". This makes it seem to the inexperienced user, such as myself, as if "Skir" was the default and therefor correct variant of the icon theme. Please excuse that for this example I dismissed the existence of "Sifr (SVG)" and "Sifr (SVG + dark)" I think a more sensible naming convention regarding the above example would be to call the icons themes "Sifr (light)" and "Sifr (dark)". This would make it clear to the user that the former theme is to be used with the light and the latter with the dark mode. Unless of course the user assumes "Sifr (light)" means that it's displayed using "light" colours 😅. This would also give us a chance to introduce a new variant of the icon theme called "Sifr (automatic)". The goal of this theme would be to automatically decide the correct variant of theme for the user. While this wouldn't really eliminate "Benjamins" problem, it would make it a tiny bit easier to switch between themes. If however, a user chose a more specific icon theme, like "Sfir (dark)" or "Sfir (SVG), I think it would be better to inform the user that there might be too low contrast and that it would be better if he adjusted the icon theme. I think those two options of introducing a new variant of the icon themes and informing the user of the low contrast could be split into two separate features as the former might be a bit easier to implement. I would be more than happy to try and implement the first feature, but seeing as this would be my first time working on this project I'd probably need some pointers of someone who is a bit more familiar with the code base. I'm also curious to hear what you think of my idea. I do ask you to show some compassion though, as this is my very first comment on this forum.
(In reply to documentfoundation.msyjk from comment #10) Rework of the icon theming is at core of bug 148764 -- the meta details and potential adoption of the freedesktop.org packaging specification [1]. Appearance theming implemented at 25.2, and modified at 25.8, now offers potential to bring icon theme choices under UI configuration. Currently the icon themes as listed for selection are each independently packaged. They have descriptive naming, but require user selection (and often restart of module or full LO UI). Most effective way forward would be the packaging with meta details of the full icon themes light/dark, SVG, HC a11y suitability. =-ref-= [1] https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
(In reply to documentfoundation.msyjk from comment #10) While a tweak of the names might improve things slightly - that's not strong enough of a measure. I agree with Stuart: They way forward passes through a revamp of the icon theme format so that it provides appropriate meta-data; and then, either the Appearance tab code or the code that's invoked when you Apply should have a verification introduced of the icon theme agreeing with the general theme / color scheme. I'm not an LO developer myself, but it seems like the work on 148764 should not be that daunting - the LO part of the code should be pretty localized and you would be writing some new loader/parser code for this format (or adapting existing code from another project). So I would encourage you to pursue that. But - of course, only if you feel like it and have the time, and no pressure. Welcome to BugZilla, and users' input is always welcome (which is not to say there isn't often staunch disagreement about potential courses of action...)