Description: As "http://i.redd.it/ecdrtquwed691.png" depicts, the page does not adhere to the theme of the system automatically. This is present within Web View too, which easily demonstrates why this feature is necessary and obviously should already be present. Steps to Reproduce: Apply any theme to your device and observe how LibreOffice's page does not adhere to my colourative customization, but rather to custom colouration. Actual Results: LibreOffice's page does not adhere to my colourative customization, but rather to its custom colourative preference. Expected Results: LibreOffice's page should adhere to my colourative customization, but rather to its custom colourative preference. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: The provided "LibreOffice Dark Theme" is inadequate even as a manual method of remediation of this problem, because it is infeasible to maintain by those that frequently replace the theme of their system, and is able to be unpleasant if, during daytime, the light version was utilized, and has not been switched to the dark theme before LibreOffice is invoked during darkness.
There have been many improvements to the dark theme functionality. 7.5 was released with the improvements and there is also this much-requested thing coming in 7.5.1: bug 153229. Is there anything missing in 7.5 in your opinion? Set to NEEDINFO. Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.
Dear BEEDELL ROKE JULIAN LOCKHART, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Created attachment 189162 [details] Depiction of the problem. https://bugs.documentfoundation.org/show_bug.cgi?id=149611#c1
> https://ask.libreoffice.org/t/how-to-make-writer-page-adhere-to-system-lo-theme/95069/2?u=rokejulianlockhart No, although it is a significant improvement.
Can not confirm on Windows builds of 7.6.0.3 or of recent master against 24.2.0 For work done on see also bug 153229 From Start Center --> Tools --> Options --> Application colors the the default 'Automatic' Custom colors "scheme" offers three choices in the 'Automatic' list box: 'System theme', 'Light' (the Default), or 'Dark' On Windows 10 os/DE the 'System theme' selection *does* provide a dark canvas bg with contrasting fg. While the default 'Light' selection maintains legacy behavior. And, 'Dark' forces the LIbreOffice UI into a Dark mode. Unable to test against Linux os/DE flavors at the moment--but this => WFM
Thanks for that. It's great to hear. Hopefully this is just a bug experienced by KDE users.
Created attachment 189181 [details] GNOME - System Theme (Dark) Page - Writer
Created attachment 189182 [details] GNOME - System Theme (Light) Page - Writer (also see dark mode in picture above) Since the pictures provided by some users show a problem regarding dark theme on linux, I want to post here that it had been RESOLVED in the current daily build (maybe earlier too). For reference, here's my post from ask.libreoffice.org: https://ask.libreoffice.org/t/how-to-make-writer-page-adhere-to-system-lo-theme/95069/13?u=thesmallest I downloaded the daily build from 2023-Aug-27 here: https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@tb99-TDF/2023-08-27_04.31.13/LibreOfficeDev_24.2.0.0.alpha0_Linux_x86-64_deb.tar.gz. System info (inside virtualbox): OS: Debian GNU/Linux 12 (bookworm) 64-bit Windowing system: Wayland DE: Gnome Libreoffice version (help > about): Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e16e84c44fc7517529c8a183fbd8f97c0c3e380e CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded I had to go and change "automatic" from "light" (default) to "system theme" in options > application colors first. Also if I change gnome from light to dark (and vice versa) while the above mentioned libreoffice is still opened, the theme gets applied immediatly and correctly. Not sure if I should set the status to RESOLVED here. See attachments for screenshots.
Can you confirm that the behaviour is actually different to the version I quoted? I can't easily test anything newer than what I'm using currently. If the listed version is indeed as I describe, and the newer version as you describe, set this as resolved. Better defaults would be a separate issue.
(In reply to third="Beedell", first="Roke" from comment #9) > Can you confirm that the behaviour is actually different to the version I > quoted? I can't easily test anything newer than what I'm using currently. If > the listed version is indeed as I describe, and the newer version as you > describe, set this as resolved. Better defaults would be a separate issue. Okay, so (on GNOME): LO versions 7.3.4.2 and 7.4.7.2: If I turn on dark theme in my OS, nothing in LO changes. UI stays like it does in light mode, page doesn't change. However, if I go to tools > options > application colors and choose "Libreoffice Dark" in "Scheme", then the page changes to black (and black text is displayed white). UI doesn't change, no matter what I do. In LO version 24.2.0.0.alpha0+ it works as intended (after changing the setting as described). LO will apply the appropriate theme (ui and page) and you don't have to change anything yourself once you changed that setting I described in comment #8. So yes: I can confirm that the behavior is different than on your system. However, I also downloaded KDE Plasma (5.27.5 under wayland) with debian 12, since you mentioned you use it: LO version 7.3.4.2: If your plasma is set to dark (settings > appearance > global theme > breeze dark) LO ui changes to black as well as the page. Works exactly as intended. LO version 7.4.7.2: Page goes black, ui stays like it would in light mode. LO version 24.2.0.0.alpha0+: UI changes accordingly, page *only* if manually set to dark, else it stays white. However, ui changes according to the system if I turn on / off dark mode. (tested with KDE plasma in X11 and same happens) I noticed warnings in the terminal if I execute LO 24.2.0.0.alpha0+ (with KDE) regarding VCL. Seems like it fails to load icons and images but I don't know how that's related to the page display. I also set SAL_USE_VCLPLUGIN=gen and opened LO 24.2.0.0.alpha0+ with the terminal again. Now neither the page nor the ui change to dark mode (SAL_USE_VCLPLUGIN=gtk is the default). I'll change the status to NEW, since it seems to be an KDE plasma related bug. Also, it's NOT RESLOVED for KDE plasma.
(In reply to Caolán McNamara from bug 153229 comment 39) > (In reply to Heiko Tietze from comment #35) > > The dropdown is hidden on Linux/Qt but shown when running with > > SAL_USE_VCLPLUGIN gtk3/gtk4. > > As far as I know there isn't explicit dark mode support in the qt/kf > backend. It already doesn't seem to "know" if its in dark mode in order to > automatically select an appropriate icon theme. For me with hidpi and > wayland a lot of the basic functionality is not really functional with > misplaced menus and awkward font sizes. If we want to enable it for qt/kf > then someone else will have to figure out how to do it. I suggest to resolve this ticket as NAB and to create another follow-up to bug 153229 (which introduced the appearance switch) for kf5/qt6. Meanwhile, you can manually switch to the dark application colors, see bug 152184.
(In reply to Heiko Tietze from comment #11) > I suggest to resolve this ticket as NAB and to create another follow-up to > bug 153229 (which introduced the appearance switch) for kf5/qt6. > > Meanwhile, you can manually switch to the dark application colors, see bug > 152184. Let's just use this bug report for that. Pending Gerrit change that makes kf5/qt6 automatically use dark application colors when "Tools" -> "Options" -> "LibreOffice(Dev)" -> "Application Colors" -> "Automatic" is set to "System Theme" and a dark theme is used in KDE Plasma. https://gerrit.libreoffice.org/c/core/+/156467
I can confirm that LO 7.6 Writer (snap id CpUkI0qPIIBVRsjy49adNq4D6Ra72y4v from `snap install --channel=latest/edge`) uses the dark theme on cpe:/o:opensuse:tumbleweed:20230828, unlike https://download.opensuse.org/repositories/openSUSE:/Factory/standard/x86_64/libreoffice-7.6.1.1-1.1.x86_64.rpm
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/19b8bac2aa59d02968c33ac6f83c66907d5ab94c tdf#149611 qt: Make auto-selection of dark app colors work It will be available in 24.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.
(In reply to third="Beedell", first="Roke" from comment #13) > I can confirm that LO 7.6 Writer (snap id CpUkI0qPIIBVRsjy49adNq4D6Ra72y4v > from `snap install --channel=latest/edge`) uses the dark theme on > cpe:/o:opensuse:tumbleweed:20230828, unlike > https://download.opensuse.org/repositories/openSUSE:/Factory/standard/x86_64/ > libreoffice-7.6.1.1-1.1.x86_64.rpm Possibly the former is using the gtk3 VCL plugin while the latter uses kf5. This can bee senn in "Help" -> "About LibreOffice". With the commit from commit 14, auto-selection should work with the kf5 VCL plugin as well, so I'm closing this bug as fixed.
> Possibly the former is using the gtk3 VCL plugin while the latter uses kf5. > This can bee senn in "Help" -> "About LibreOffice". You're correct.
(In reply to Commit Notification from comment #14) > Michael Weghorn committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 19b8bac2aa59d02968c33ac6f83c66907d5ab94c > > tdf#149611 qt: Make auto-selection of dark app colors work > > It will be available in 24.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. CONFIRMED FIXED with current daily in KDE Plasma (5.27.5). Downloaded from: https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@tb99-TDF/2023-09-03_04.38.37/LibreOfficeDev_24.2.0.0.alpha0_Linux_x86-64_deb.tar.gz About > help: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 3c7a35dd28fbc337a23473873b3dd47392b883ae CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Had to set following setting first: Options > LibreofficeDev > Application colors > Automatic > System Theme. Also checked with GNOME – no breakage found. System info (inside virtualbox): OS: Debian GNU/Linux 12 (bookworm) 64-bit Windowing system: Wayland
(In reply to Thesmallest from comment #17) > CONFIRMED FIXED with current daily in KDE Plasma (5.27.5). Great, thanks!
(In reply to Michael Weghorn from comment #18) > (In reply to Thesmallest from comment #17) > > CONFIRMED FIXED with current daily in KDE Plasma (5.27.5). > > Great, thanks! Per https://ask.libreoffice.org/t/automatic-system-theme-should-set-document-colour-to-theme-colours/100696/5?u=rokejulianlockhart, it seems to me like that this has reappeared. I'm using https://download.opensuse.org/repositories/openSUSE:/Factory/standard/x86_64/plasma5-desktop-5.27.10-1.1.x86_64.rpm on cpe:/o:opensuse:tumbleweed:20240118. Can anyone reproduce?
(In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #19) > (In reply to Michael Weghorn from comment #18) > > (In reply to Thesmallest from comment #17) > > > CONFIRMED FIXED with current daily in KDE Plasma (5.27.5). > > > > Great, thanks! > > Per > https://ask.libreoffice.org/t/automatic-system-theme-should-set-document- > colour-to-theme-colours/100696/5?u=rokejulianlockhart, it seems to me like > that this has reappeared. I'm using > https://download.opensuse.org/repositories/openSUSE:/Factory/standard/x86_64/ > plasma5-desktop-5.27.10-1.1.x86_64.rpm on > cpe:/o:opensuse:tumbleweed:20240118. Can anyone reproduce? In the forum topic, you say you use 7.6.4.1 while this fix is only in 24.2.0. Can you try with 24.2.0, please?
(In reply to Buovjaga from comment #20) > (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #19) > > (In reply to Michael Weghorn from comment #18) > > > (In reply to Thesmallest from comment #17) > > > > CONFIRMED FIXED with current daily in KDE Plasma (5.27.5). > > > > > > Great, thanks! > > > > Per > > https://ask.libreoffice.org/t/automatic-system-theme-should-set-document- > > colour-to-theme-colours/100696/5?u=rokejulianlockhart, it seems to me like > > that this has reappeared. I'm using > > https://download.opensuse.org/repositories/openSUSE:/Factory/standard/x86_64/ > > plasma5-desktop-5.27.10-1.1.x86_64.rpm on > > cpe:/o:opensuse:tumbleweed:20240118. Can anyone reproduce? > > In the forum topic, you say you use 7.6.4.1 while this fix is only in > 24.2.0. Can you try with 24.2.0, please? Indeed, you're correct - `sudo snap install libreoffice --channel=latest/beta` with the same preferences worked: https://ask.libreoffice.org/t/automatic-system-theme-should-set-document-colour-to-theme-colours/100696/6?u=rokejulianlockhart.
Created attachment 194382 [details] KDE Plasma 6.0.5 - System Theme (Dark) Page - Writer
Created attachment 194396 [details] KDE Plasma 6.0.5 - System Theme (Dark) Automatic Colours - Writer
(In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #22) > Created attachment 194382 [details] > KDE Plasma 6.0.5 - System Theme (Dark) Page - Writer I'd like to reopen this, because it's not working in Fedora 40's RPM: Version: 24.2.3.2 (X86_64) Build ID: 420(Build:2) CPU threads: 12; OS: Linux 6.8; UI render: default; VCL: kf6 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded I'm using https://koji.fedoraproject.org/koji/rpminfo?rpmID=38510610.
Comment on attachment 189181 [details] GNOME - System Theme (Dark) Page - Writer (In reply to Thesmallest from comment #8) > Created attachment 189182 [details] > GNOME - Light Theme - Writer > > (also see dark mode in picture above) > > I had to go and change "automatic" from "light" (default) to "system theme" > in options > application colors first. > > Also if I change gnome from light to dark (and vice versa) > > See attachments for screenshots.
Comment on attachment 189182 [details] GNOME - System Theme (Light) Page - Writer (In reply to Thesmallest from comment #8) > Created attachment 189182 [details] > GNOME - Light Theme - Writer > > (also see dark mode in picture above) > > I had to go and change "automatic" from "light" (default) to "system theme" > in options > application colors first. > > Also if I change gnome from light to dark (and vice versa) > > See attachments for screenshots.
(In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #24) > I'd like to reopen this, because it's not working in Fedora 40's RPM: > > Version: 24.2.3.2 (X86_64) > Build ID: 420(Build:2) > CPU threads: 12; OS: Linux 6.8; UI render: default; VCL: kf6 (cairo+wayland) > Locale: en-GB (en_GB.UTF-8); UI: en-US > Calc: threaded Is this with "Tools" -> "Options" -> "LibreOffice" -> "Application Colours" set to "Automatic": "System Theme"? And if so, what happens if you explicitly change that to "Dark"?
(In reply to Michael Weghorn from comment #27) > (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #24) > > I'd like to reopen this, because it's not working in Fedora 40's RPM: > > > > Version: 24.2.3.2 (X86_64) > > Build ID: 420(Build:2) > > CPU threads: 12; OS: Linux 6.8; UI render: default; VCL: kf6 (cairo+wayland) > > Locale: en-GB (en_GB.UTF-8); UI: en-US > > Calc: threaded > > Is this with "Tools" -> "Options" -> "LibreOffice" -> "Application Colours" > set to "Automatic": "System Theme"? > > And if so, what happens if you explicitly change that to "Dark"? https://bugs.documentfoundation.org/show_bug.cgi?id=159303#c13 occurs - hard-coded values equating to Adwaita-Dark's colours are utilized instead, which is incorrect for KDE. That issue should be listed in this issue's "See Also". Why do you ask?
(In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #28) > > Is this with "Tools" -> "Options" -> "LibreOffice" -> "Application Colours" > > set to "Automatic": "System Theme"? > > > > And if so, what happens if you explicitly change that to "Dark"? > > https://bugs.documentfoundation.org/show_bug.cgi?id=159303#c13 occurs - > hard-coded values equating to Adwaita-Dark's colours are utilized instead, > which is incorrect for KDE. That issue should be listed in this issue's "See > Also". From what I can see, it already is. > Why do you ask? To narrow down whether this is an issue with detecting that dark mode should be used or whether something goes wrong applying dark theme colors. According to your reply, it seems to be a problem with the former. Potentially something goes wrong with this check for some reason: bool QtFrame::GetUseDarkMode() const { #if QT_VERSION >= QT_VERSION_CHECK(6, 5, 0) const QStyleHints* pStyleHints = QApplication::styleHints(); return pStyleHints->colorScheme() == Qt::ColorScheme::Dark; #else // use same mechanism for determining dark mode preference as xdg-desktop-portal-kde, s. // https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/blob/0a4237549debf9518f8cfbaf531456850c0729bd/src/settings.cpp#L213-227 const QPalette aPalette = QApplication::palette(); const int nWindowBackGroundGray = qGray(aPalette.window().color().rgb()); return nWindowBackGroundGray < 192; #endif } Can you please create a new bug report, so the issue with kf6 (potentially Qt >= 6.5) can be tracked further? I'm closing this one here again as fixed again. (Having a clear scope for each ticket is very helpful to keep track and a good overview.)
(In reply to Michael Weghorn from comment #29) > (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #28) > > > Is this with "Tools" -> "Options" -> "LibreOffice" -> "Application Colours" > > > set to "Automatic": "System Theme"? > > > > > > And if so, what happens if you explicitly change that to "Dark"? > > > > https://bugs.documentfoundation.org/show_bug.cgi?id=159303#c13 occurs - > > hard-coded values equating to Adwaita-Dark's colours are utilized instead, > > which is incorrect for KDE. That issue should be listed in this issue's "See > > Also". > > From what I can see, it already is. Indeed. It's a fault of my dialect that I used "should be" instead of "is". Apologies. > > Why do you ask? > > To narrow down whether this is an issue with detecting that dark mode should > be used or whether something goes wrong applying dark theme colors. > According to your reply, it seems to be a problem with the former. > > Can you please create a new bug report, so the issue with kf6 (potentially > Qt >= 6.5) can be tracked further? > I'm closing this one here again as fixed again. > (Having a clear scope for each ticket is very helpful to keep track and a > good overview.) Certainly. I'll link it when I've done so. Thanks.
(In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #30) > > To narrow down whether this is an issue with detecting that dark mode should > > be used or whether something goes wrong applying dark theme colors. > > According to your reply, it seems to be a problem with the former. > > > > Can you please create a new bug report, so the issue with kf6 (potentially > > Qt >= 6.5) can be tracked further? > > I'm closing this one here again as fixed again. > > (Having a clear scope for each ticket is very helpful to keep track and a > > good overview.) > > Certainly. I'll link it when I've done so. Thanks. Actually, I'll wait to see what the reaction to https://bugs.documentfoundation.org/show_bug.cgi?id=159303#c16 is. I'll continue any other discussion about the "Dark" preset over there.
(In reply to Michael Weghorn from comment #29) > Potentially something goes wrong with this check for some reason: > > bool QtFrame::GetUseDarkMode() const > { > #if QT_VERSION >= QT_VERSION_CHECK(6, 5, 0) > const QStyleHints* pStyleHints = QApplication::styleHints(); > return pStyleHints->colorScheme() == Qt::ColorScheme::Dark; > #else > // use same mechanism for determining dark mode preference as > xdg-desktop-portal-kde, s. > // > https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/blob/ > 0a4237549debf9518f8cfbaf531456850c0729bd/src/settings.cpp#L213-227 > const QPalette aPalette = QApplication::palette(); > const int nWindowBackGroundGray = qGray(aPalette.window().color().rgb()); > return nWindowBackGroundGray < 192; > #endif > } > > Can you please create a new bug report, so the issue with kf6 (potentially > Qt >= 6.5) can be tracked further? > I'm closing this one here again as fixed again. > (Having a clear scope for each ticket is very helpful to keep track and a > good overview.) OK, I tried and can reproduce on Fedora Rawhide with system Qt 6.7.1. It's also reproducible with a simple sample application like this: ``` #include <iostream> #include <QApplication> #include <QStyleHints> int main(int argc, char* argv[]) { QApplication a(argc, argv); const QStyleHints* pStyleHints = QApplication::styleHints(); Qt::ColorScheme colorScheme = pStyleHints->colorScheme(); qWarning() << colorScheme; return a.exec(); } ``` When running this with the system-provided Qt on Fedora Rawhide, I get this: $ ./test-colors libEGL warning: egl: failed to create dri2 screen MESA: error: ZINK: failed to choose pdev libEGL warning: egl: failed to create dri2 screen Qt::ColorScheme::Unknown -> cannot detect the right color theme. However, when I run this with a self-compiled current development version of Qt (qtbase git dev as of commit e0d87f70d87a63aa55a11ecb91f8d355767d61bd) instead, this behaves as expected. With "Breeze" selected for the system theme: $ LD_LIBRARY_PATH=/home/user/development/git/qt5/qtbase/lib ./test-colors qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in "" Qt::ColorScheme::Light With "Breeze Dark": $ LD_LIBRARY_PATH=/home/user/development/git/qt5/qtbase/lib ./test-colors qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in "" Qt::ColorScheme::Dark Running a self-compiled LibreOffice master with that Qt development version also behaves correctly, while the issue you described is seen with system Qt. So this looks like a Qt issue to me, presumably already fixed upstream. This here sounds like it might be the corresponding bug report (and the commits linked there the fixes then): https://bugreports.qt.io/browse/QTBUG-125285 If so, that should be fixed in Qt 6.7.2. If you still see the issue with a newer Qt version, feel free to create a new bug report, but from all I can see so far, the root cause is somewhere outside of LO.
Created attachment 194407 [details] KDE Plasma 6.0.5 - Writer - Video Demonstration
(In reply to Michael Weghorn from comment #32) > So this looks like a Qt issue to me, presumably already fixed upstream. > This here sounds like it might be the corresponding bug report (and the > commits linked there the fixes then): > https://bugreports.qt.io/browse/QTBUG-125285 > > If so, that should be fixed in Qt 6.7.2. > If you still see the issue with a newer Qt version, feel free to create a > new bug report, but from all I can see so far, the root cause is somewhere > outside of LO. Thank you. As I've probably put in a log somewhere, I'm using Qt 6.7.0, so I'll wait until my Qt version has been increased, and then upgrade. Many, many thanks for such in-depth diagnosis on my behalf.
(In reply to `{3rd: "Beedell", 1st: "Roke"}`{.JSON5} from comment #34) > As I've probably put in a log somewhere, I'm using Qt 6.7.0, so > I'll wait until my Qt version has been increased, and then upgrade. I've not forgotten this, but Plasma 6 has been on 6.7.1 for a while now - it's taking ages to get to .7.2. I'll ensure that I test LO Writer when it updates.
Created attachment 195239 [details] KDE Plasma 6.1.1 (Qt 6.7.2) - System Theme (Dark) Page - Writer (In reply to `{3rd: "Beedell", 1st: "Roke"}`{.JSON5} from comment #35) > (In reply to `{3rd: "Beedell", 1st: "Roke"}`{.JSON5} from comment #34) > > As I've probably put in a log somewhere, I'm using Qt 6.7.0, so > > I'll wait until my Qt version has been increased, and then upgrade. > > I've not forgotten this, but Plasma 6 has been on 6.7.1 for a while now - > it's taking ages to get to .7.2. I'll ensure that I test LO Writer when it > updates. I'm on 6.7.2: Operating System: Fedora Linux 40 KDE Plasma Version: 6.1.1 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 Kernel Version: 6.9.8-200.fc40.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 7600X 6-Core Processor Memory: 30.5 GiB of RAM Graphics Processor: AMD Radeon RX 5700 Manufacturer: ASRock Product Name: X670E Taichi ...and it's identical.
As mentioned, please create a new report.
(In reply to Buovjaga from comment #37) > As mentioned, please create a new report. Apologies. Forgot since last message. I've filed https://bugs.documentfoundation.org/show_bug.cgi?id=162003.