Description: In "Tabbed" or "Grouped Compact" toolbar modes, switching between light and dark GTK theme (Adwaita) does not refresh the styling of the toolbars. Starting a new window or changing the toolbar style works around the issue. Steps to Reproduce: 1. Set LibreOffice's toolbar UI to either "Tabbed" or "Grouped Compact" 2. Open gnome-tweak-tool 3. While a LibreOffice Writer/Calc/etc. GUI is open, switch the GTK theme from "Adwaita Dark" to "Adwaita", or from "Adwaita" to "Adwaita Dark". Actual Results: The GUI adapts to the new theme, except the main toolbar. Particularly, the combobox/dropdown widgets change their font color but not the widget's background color, leading to illegible text. Expected Results: The main toolbar should adapt, like the rest. Reproducible: Always User Profile Reset: Yes Additional Info: See attached screenshots. Tested on Fedora 30 (the latest stable Fedora version available to me), hence the LibreOffice 6.2.x version.
Created attachment 154202 [details] light to dark When the app was started with the light theme
Created attachment 154203 [details] dark to light When the app was started with the dark theme
Ordinary bug, please fix it.
Reproduced with recent master build, using the GNOME 3.36 light and dark modes (in GNOME settings > Appearance). Both "Tabbed" and "Groupedbar compact" UIs are affected. Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 1dd4a80fa076bedb3a82821517036bad8dd79857 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-07-26_22:41:19 Calc: threaded
Created attachment 174015 [details] GNOME from light to dark in tabbed UI, LO 7.3 alpha0+
Created attachment 174016 [details] GNOME from dark to light in groupedbar compact UI, LO 7.3 alpha0+
It may now be easier for the app to handle this, as there now is a standardized (i.e. FreeDesktop) way for LibreOffice to authoritatively know, without just trying to "guess" whether the current GTK theme is dark or not, what the user's intent is in terms of light/dark themes. * Overview here: https://blogs.gnome.org/alexm/2021/10/04/dark-style-preference/ * Implementation tips here: https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/Dark-Style-Preference Presumably this would let LibreOffice connect to a clear standardized signal, which would allow it to confidently switch over (& refresh) its themes internally when needed.
After seeing https://caolanm.blogspot.com/2022/05/dark-style-preference-with-gtk.html I was eagerly awaiting LibreOffice 7.5, presuming that this would be fixed, but it seems this particular issue here (and bug #127138, for the icons, and possibly others related to bug #143344) was not included/taken into account as part of the implementation, as I'm still seeing the same behavior on the version available from Flathub: Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Flatpak GNOME 43 makes it easier to test than before, as you can simply toggle global dark mode on and off at any time from the system menu in the corner of the screen, so you can check how LibreOffice behaves with the transition. It works for the "Standard toolbar" UI layout (and it even seems to automatically switch the icon theme there?!), but not for "Tabbed", "Tabbed compact" or "Groupedbar compact". I wonder if the implementation in 7.5 makes it simple enough to address as part of a point release within that series (maybe as an "easyHack"?), or if this will require a whole major release cycle.
The TabBar/muffin/ribbon thing doesn't use "real" gtk widgets so it doesn't behave out of the box like the rest
Created attachment 185355 [details] Tabbed toolbars behavior in 7.5.0.3 when switching from light to dark, and when forcing a toolbar refresh @Caolán: Oh, that might explains some things... Though, have a look at this new screenshot here, and consider this naïve question of mine: it seems like the "tabbed" toolbars, as well as the "groupedbar compact", in version 7.5, do render 100% correctly (which wasn't the case before) "when the toolbars are rendered/initialized" (i.e. by switching toolbar UI layout modes) _after_ the dark/light switch has occurred... in other words, it appears to that it simply doesn't do that forced refresh upon dark/light switch. So my thinking is, and maybe this will sound ridiculous: would it make sense for your code (upon live dark/light switch event) to call the same kind of method that is called when the user manually switches between toolbar UI layouts (which leads to the 3rd result, at the bottom of my newest attached screenshot here, which looks fine in 7.5.x), or is that a really nasty incorrect approach? Just a random idea in case it can be useful :)
finally managed to carve out a little time to look at the notebookbar, it wasn't getting any of the existing Settings update notifications due to the non-standard way its wedged into the hierarchy. Its possible that my up and coming fix won't solve everything but should put things on the right path at least. *** This bug has been marked as a duplicate of bug 153541 ***