Summary: | In "Tabbed" or "Grouped Compact" toolbar modes, switching between light and dark GTK themes does not refresh the styling of the toolbars | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Jeff Fortin Tam <nekohayo> |
Component: | UI | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | caolan.mcnamara, heiko.tietze, stephane.guillou, steven.h.bach, xiscofauli |
Priority: | medium | ||
Version: | 6.2.7.1 release | ||
Hardware: | All | ||
OS: | Linux (All) | ||
See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=127138 https://bugs.documentfoundation.org/show_bug.cgi?id=153353 |
||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 103184, 103303, 107191, 143344 | ||
Attachments: |
light to dark
dark to light GNOME from light to dark in tabbed UI, LO 7.3 alpha0+ GNOME from dark to light in groupedbar compact UI, LO 7.3 alpha0+ Tabbed toolbars behavior in 7.5.0.3 when switching from light to dark, and when forcing a toolbar refresh |
Description
Jeff Fortin Tam
2019-09-16 20:19:34 UTC
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 *** |