Created attachment 195240 [details] KDE Plasma 6.1.1 (Qt 6.7.2) - System Theme (Dark) Page - Writer Environment ----------- > Version: 24.2.4.2 (X86_64) > Build ID: 420(Build:2) > CPU threads: 12; OS: Linux 6.9; UI render: default; VCL: kf6 (cairo+wayland) > Locale: en-GB (en_GB.UTF-8); UI: en-US > Calc: threaded --- The attachment is from [the previous issue](https://bugs.documentfoundation.org/attachment.cgi?id=195239&action=edit).
Created attachment 195241 [details] KDE Plasma 6.1.1 (Qt 6.7.2) - System Theme (Dark) Page - Calc
(In reply to `{3rd: "Beedell", 1st: "Roke"}`{.JSON5} from comment #0) > Created attachment 195240 [details] > KDE Plasma 6.1.1 (Qt 6.7.2) - System Theme (Dark) Page - Writer > > Environment > ----------- > > > Version: 24.2.4.2 (X86_64) > > Build ID: 420(Build:2) > > CPU threads: 12; OS: Linux 6.9; UI render: default; VCL: kf6 (cairo+wayland) > > Locale: en-GB (en_GB.UTF-8); UI: en-US > > Calc: threaded The package I'm using is [`libreoffice-1:24.2.4.2-2.fc40.x86_64.rpm`](https://koji.fedoraproject.org/koji/rpminfo?rpmID=38810122) on [cpe:/o:fedoraproject:fedora:40](https://download.fedoraproject.org/pub/fedora/linux/releases/40/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-40-1.14.iso).
Repro steps? If per bug 149611 comment 27 I do "Tools" -> "Options" -> "LibreOffice" -> "Application Colours" set to "Automatic": "Dark", I get a dark canvas in all the apps. As far as I understand, adapting it from *the system theme* would be the enhancement request of bug 159303, right? And the ball still seems to be on KDE's court with that one. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 35e5abe8e569c67fbb0afe84afbd826373470a8c CPU threads: 8; OS: Linux 6.9; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded
(In reply to Buovjaga from comment #3) > Repro steps? > > If per bug 149611 comment 27 I do "Tools" -> "Options" -> "LibreOffice" -> > "Application Colours" set to "Automatic": "Dark", I get a dark canvas in all > the apps. Indeed, those are the reproduction steps - this is a direct inheritor of the history of https://bugs.documentfoundation.org/show_bug.cgi?id=149611#c36 and before, so its reproduction steps are identical. > As far as I understand, adapting it from *the system theme* would be the > enhancement request of bug 159303, right? And the ball still seems to be on > KDE's court with that one. That's separate - that's about the "Dark" theme. This issue refers to the "System theme" configuration.
(In reply to `{3rd: "Beedell", 1st: "Roke"}`{.JSON5} from comment #4) > (In reply to Buovjaga from comment #3) > > Repro steps? > > > > If per bug 149611 comment 27 I do "Tools" -> "Options" -> "LibreOffice" -> > > "Application Colours" set to "Automatic": "Dark", I get a dark canvas in all > > the apps. > > Indeed, those are the reproduction steps - this is a direct inheritor of the > history of https://bugs.documentfoundation.org/show_bug.cgi?id=149611#c36 > and before, so its reproduction steps are identical. > > > As far as I understand, adapting it from *the system theme* would be the > > enhancement request of bug 159303, right? And the ball still seems to be on > > KDE's court with that one. > > That's separate - that's about the "Dark" theme. This issue refers to the > "System theme" configuration. Unfortunately, as LibreOffice has developed, this bug has become more complex. To summarise concisely:
> Unfortunately, as LibreOffice has developed, this bug has become more > complex. To summarise concisely: Sorry. Didn't mean to post that. I'm polluting the comment history now. To summarise: 1. Originally, "Dark" used a static entry in the preset, keyed to Adwaita Dark. 2. "System theme" was added, which didn't work, and didn't even bother to utilize "Dark" as a fallback when it couldn't find the dark theme, so it fell and continues to fall back to "Light" instead of what it should be doing, which is polling for the system theme. 3. At some point, "Dark" and "Light" were both modified such that they utilize entirely "Automatic" values. However, the values they choose remain exactly what they used to - erroneously - be. Across all the aforereferenced bugs, we need to: 1. Have "System theme" choose the correct theme. 2. Have "Dark" utilize the DE's dark colour scheme's values. I don't know whether this depends upon https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2567, per the attached screenshot (since you can't set something like a "Day" and "Night" theme yet).
(In reply to Buovjaga from comment #3) > Repro steps? > > If per bug 149611 comment 27 I do "Tools" -> "Options" -> "LibreOffice" -> > "Application Colours" set to "Automatic": "Dark", I get a dark canvas in all > the apps. Works fine for me on Debian testing as well when using the qt6 VCL plugin, with both, system Qt (6.6.2+dfsg-9) and self-compiled Qt (git dev as of qtbase commit 46ffca13fb0705c54ad05bc2c1a37f7d5fb5132d). > As far as I understand, adapting it from *the system theme* would be the > enhancement request of bug 159303, right? And the ball still seems to be on > KDE's court with that one. Yes, let's leave discussion about that one in there. KDE libs might already be providing the information needed, would need checking. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1c892a7729234202e6ce14e116e91786b248835a CPU threads: 32; OS: Linux 6.9; UI render: default; VCL: qt6 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Created attachment 195256 [details] Sample Qt program to print style info
As mentioned in tdf#149611 comment 32, for Qt >= 6.5, LO depends on Qt to detect whether a light or dark style is used. attachment 195256 [details] is a slightly extended version of the sample program mentioned there. Can you please test that one? To build: Extract the zip file and `cd` into the directory, then: $ qmake6 Info: creating stash file /tmp/qt-print-style-info/.qmake.stash $ make g++ -c -pipe -O2 -std=gnu++1z -Wall -Wextra -D_REENTRANT -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I. -I/usr/include/x86_64-linux-gnu/qt6 -I/usr/include/x86_64-linux-gnu/qt6/QtWidgets -I/usr/include/x86_64-linux-gnu/qt6/QtGui -I/usr/include/x86_64-linux-gnu/qt6/QtCore -I. -I/usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++ -o main.o main.cpp g++ -Wl,-O1 -Wl,-rpath-link,/usr/lib/x86_64-linux-gnu -o qt-print-style-info main.o /usr/lib/x86_64-linux-gnu/libQt6Widgets.so /usr/lib/x86_64-linux-gnu/libQt6Gui.so /usr/lib/x86_64-linux-gnu/libGLX.so /usr/lib/x86_64-linux-gnu/libOpenGL.so /usr/lib/x86_64-linux-gnu/libQt6Core.so -lpthread -lGLX -lOpenGL Running with Plasma global theme set to "Breeze Dark" in Debian testing (still using Plasma 5 and doesn't ship a KF 6 Breeze style yet, so falls back to "fusion"): $ ./qt-print-style-info Style: "fusion" Color scheme: Qt::ColorScheme::Dark ^C Running with global theme set to "Breeze": $ ./qt-print-style-info Style: "fusion" Color scheme: Qt::ColorScheme::Light ^C -> That gives the correct result. What does it print for you?
Also, what's you the global theme you're setting in KDE system settings?
(In reply to Michael Weghorn from comment #9) > As mentioned in tdf#149611 comment 32, for Qt >= 6.5, LO depends on Qt to > detect whether a light or dark style is used. > > [...] > > -> That gives the correct result. What does it print for you? I can reproduce the problem now in a self-built Plasma Dev session. The output there is $ ./qt-print-style-info Style: "breeze" Color scheme: Qt::ColorScheme::Unknown regardless of what theme is selected. From what I can see, the problem is in plasma-integration not reporting the color scheme. Suggested MR to fix that: https://invent.kde.org/plasma/plasma-integration/-/merge_requests/149 For now, we can still add a workaround for the case where Qt::ColorScheme::Unknown is reported and fall back to the same mechanism that gets used for Qt <= 6.5.
(In reply to Michael Weghorn from comment #11) > For now, we can still add a workaround for the case where > Qt::ColorScheme::Unknown is reported and fall back to the same mechanism > that gets used for Qt <= 6.5. -> https://gerrit.libreoffice.org/c/core/+/172467
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6b0b28d66ae79c1cbb7545b4b40dd3682f20ff72 tdf#162003 qt: Add fall back for dark mode detection It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/59a46daf21986b1cb15bc4fccae0bf2489664045 tdf#162003 qt: Add fall back for dark mode detection It will be available in 24.8.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.