SUMMARY Before recently, when opening certain KDE apps (Kate, Konsole, & Dolphin) in LXQt, the choice made in KDE System Settings --> Colors & Themes --> Global Theme was respected. For example, if Breeze Dark was selected as the Global Theme, then Kate would open with dark colors. If Breeze was selected instead (Breeze Light), then Kate would open up with bright colors. However, all 3 of these apps now open in Breeze Light mode, even if KDE's Global Theme is set to Breeze Dark. In Kate and Konsole, I can at least navigate to Settings --> Window Color Scheme and choose Default (even though it's already selected) to make the app dark like it should be after opening. I cannot seem to do this in Dolphin, however. I assumed this was a LXQt-side issue since I recently updated LXQt from 2.0.0 to 2.1.0. However, I've been told that this issue is likely caused by certain KDE apps (such as Kate, Konsole, and Dolphin) directly using whatever KDE color scheme is selected rather than using LXQt's selected color scheme via LXQt's Qt plugin (see https://github.com/lxqt/lxqt/issues/2653). This issue may have been introduced when upgrading Kate, Konsole, and Dolphin to 24.08.1 STEPS TO REPRODUCE 1. Log into LXQt. 2. Open KDE System Settings. 3. Ensure that Breeze Dark is selected in Colors & Themes --> Global Theme. Apply the changes. 4. (Probably optional) Ensure that Breeze Dark is selected in Colors & Themes --> Colors. Apply the changes. 5. Open Kate, Konsole, or Dolphin. It will be bright-colored (Breeze Light) instead of dark (Breeze Dark). OBSERVED RESULT When opening Kate, Konsole, or Dolphin, the app has Breeze Light colors. EXPECTED RESULT When opening Kate, Konsole, or Dolphin, the app has Breeze Dark colors. SOFTWARE/OS VERSIONS Linux: 6.6.62 Distro: Void Linux (x86-64 musl) KDE Plasma Version: 6.2.0 KDE Frameworks Version: 6.7.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION KDE System Settings Version: 6.2.0 KDE Appearance/Color/Theme Settings: Global Theme: Breeze Dark Colors: Breeze Dark Application Style: Breeze Plasma Style: Breeze Kate Version: 24.08.1 Konsole Version: 24.08.1 Dolphin Version: 24.08.1 Window Manager: Openbox 3.6.1 LXQt Version: 2.1.0 liblxqt Version: 2.1.0 lxqt-qtplugin Version: 2.1.0 LXQt Appearance Settings: Widget Style: QT Style: Fusion QT Palette: Ambiance LXQt Theme: Ambiance
I just tried downgrading Kate, Konsole, and Dolphin from 24.08.1 to 24.05.0 and only Dolphin opened in dark mode. Kate still required selecting Default under Settings --> Window Color Scheme to change it to dark mode after opening while this didn't work for Konsole at all.
I can't directly check since I'm not using LXQt, but I wonder if what you're seeing is somehow related to the same underlying cause as what's turned up here in more updated KDE Flatpaks on Plasma: https://bugs.kde.org/show_bug.cgi?id=494734#c3
Could you try if Frameworks 6.8 fixes this?
Can confirm on AwesomeWM on Arch
(In reply to Christoph Cullmann from comment #3) > Could you try if Frameworks 6.8 fixes this? Frameworks 6.8 seems to have made it (slightly) worse: in Kate and Konsole, I have to explicitly select "Breeze Dark" instead of "Default" in Settings --> Window Color Scheme. Thankfully, they both remember this setting every time I open them afterwards (at least for the rest of my my LXQt session), so maybe I should actually consider this an improvement, at least in a roundabout way lol. However, I still can't set Dolphin to Breeze Dark as there's no Settings --> Window Color Scheme menu.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
The issue here is on LXQt side: xdg-desktop-portal-lxqt doesn't support the XDG dark mode spec KColorSchemeWatcher uses to detect dark mode. https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop.portal.Settings.xml#L38
(In reply to Ilya Fedin from comment #7) > The issue here is on LXQt side: xdg-desktop-portal-lxqt doesn't support the > XDG dark mode spec KColorSchemeWatcher uses to detect dark mode. > > https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop. > portal.Settings.xml#L38 I think then one should report this bug to LXQt.
(In reply to Christoph Cullmann from comment #8) > (In reply to Ilya Fedin from comment #7) > > The issue here is on LXQt side: xdg-desktop-portal-lxqt doesn't support the > > XDG dark mode spec KColorSchemeWatcher uses to detect dark mode. > > > > https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop. > > portal.Settings.xml#L38 > > I think then one should report this bug to LXQt. They don't think it's a bug/issue.
(In reply to Vandino from comment #9) > (In reply to Christoph Cullmann from comment #8) > > (In reply to Ilya Fedin from comment #7) > > > The issue here is on LXQt side: xdg-desktop-portal-lxqt doesn't support the > > > XDG dark mode spec KColorSchemeWatcher uses to detect dark mode. > > > > > > https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop. > > > portal.Settings.xml#L38 > > > > I think then one should report this bug to LXQt. > > They don't think it's a bug/issue. https://github.com/lxqt/lxqt/issues/2653#issuecomment-2572314018
Perhaps he didn't get the topic. Kate is a QtWidgets app, not QML. QT_QUICK_CONTROLS_STYLE won't make a difference. FWIW, that systemsettings issue that link has screenshot for was a bug indeed, it's fixed with kirigami 6.8, it should work just fine without QT_QUICK_CONTROLS_STYLE now.
(In reply to Ilya Fedin from comment #11) > Perhaps he didn't get the topic. Kate is a QtWidgets app, not QML. > QT_QUICK_CONTROLS_STYLE won't make a difference. Are Konsole and Dolphin also QtWidgets apps? Idk if I want to forward this info to LXQt devs, because I think I've pestered them enough about this and they're very insistent that it's not an issue. I don't think they want to hear from me again regarding this matter. > FWIW, that systemsettings issue that link has screenshot for was a bug > indeed, it's fixed with kirigami 6.8, it should work just fine without > QT_QUICK_CONTROLS_STYLE now. I have kf6-kirigami 6.9.0, kirigami-addons 1.4.0, & kirigami2 5.116.0 installed and I still need QT_QUICK_CONTROLS_STYLE set to "org.kde.desktop" in LXQt for KDE Systems Setting to have proper dark colors.
> Are Konsole and Dolphin also QtWidgets apps? Yeah, they are > I have kf6-kirigami 6.9.0, kirigami-addons 1.4.0, & kirigami2 5.116.0 installed and I still need QT_QUICK_CONTROLS_STYLE set to "org.kde.desktop" in LXQt for KDE Systems Setting to have proper dark colors. Not sure what "proper dark colors" exactly means, I rather mean it shouldn't be completely fubar anymore. Assuming you're using systemsettings linked with Qt 6, of course, cause there were no kf5 release with the fix yet.
But a more relevant fact here is that they all use KColorSchemeManager. Any application that uses it will follow KColorSchemeWatcher (which uses the XDG spec on Linux) outside of Plasma, not the color scheme set in systemsettings app. If the DE you use doesn't support it, those apps won't switch to dark mode automatically but you still can switch the color scheme inside the app. If the app in question doesn't have color scheme switcher, you can request it. The request for dolphin is https://bugs.kde.org/show_bug.cgi?id=498187.
> will follow KColorSchemeWatcher (which uses the XDG spec on Linux) outside of Plasma Does KColorSchemeWatcher use the preferences set by `qt6ct`?
No, it doesn't. It just returns whether the system prefers light or dark color scheme. Then, KColorSchemeManager sets either Breeze Light or Breeze Dark.
I think I'm having a version of this bug too, or maybe what was meant to fix this. Before a recent update, when I selected “default” as the window color scheme in Kate, something I had to redo every time it opened after one point it respected by qt6ct/qt5ct color scheme, but now it just picks Breeze Light when I do that, after what seems to be the update to frameworks 6.9.0. Konsole seems to be affected by the exact same issue; I don't use any other kde software as far as I know. I don't use Plasma, which is why I use qt6ct.
You can use qt6ct-kde from AUR or darkman
(In reply to Ilya Fedin from comment #19) > You can use qt6ct-kde from AUR or darkman I have replaced qt6ct with qt6ct-kde which seems to fiunction entirely identically on the surface including using the path of the executable and restarted Kate and selected a various different colorschemes in the new qt6ct control panel but the “default” window color scheme in Kate is still “Breeze Light”. How exactly is it supposed to be different when it still seems to save it's color schemes to ~/.config/qt6ct/colors in the same format and Kate simply doesn't seem to use that? Is it supposed to communicate to Kate in a different way to use that? I should also note that from before I used qt6ct-kde already, strace revealed that kde was indeed opening ~/.config/qt6ct/colors/Darkgrey.conf, the custom color scheme I wished it to use so it's aware of it's existence, it's simply neither using it as “default” nor is it in the list of “window color schemes”.
> How exactly is it supposed to be different when it still seems to save it's color schemes to ~/.config/qt6ct/colors in the same format and Kate simply doesn't seem to use that? Is it supposed to communicate to Kate in a different way to use that? The intended usage is that you choose one of pre-made KColorSchemes, such as Breeze Dark. If you want to create your own KColorScheme, you have to create it with systemsettings.
(In reply to Ilya Fedin from comment #21) > > How exactly is it supposed to be different when it still seems to save it's color schemes to ~/.config/qt6ct/colors in the same format and Kate simply doesn't seem to use that? Is it supposed to communicate to Kate in a different way to use that? > > The intended usage is that you choose one of pre-made KColorSchemes, such as > Breeze Dark. If you want to create your own KColorScheme, you have to create > it with systemsettings. Then what's the point of installing qt6ct-kde or qt6ct at all? The way I understand it, qt6 can be configured in various ways, kde-systemsettings and qt6ct being one of those ways. Am I to read your post that KDE applications, despite respecting qt5ct and qt6ct prior now have it as feature that they ignore it and can only be configured with kde-systemsettings. If so, what's the point of QT_QPA_PLATFORMTHEME=qt6ct then and most of all, why does kate load ~/.config/qt6ct/colors/Darkgrey.conf but then does nothing with it? Surely this cannot be intended behavior as a feature and has to be a bug? And if it be intended, it seems like removing a useful feature that was their prior.
> Am I to read your post that KDE applications, despite respecting qt5ct and qt6ct prior now have it as feature that they ignore it and can only be configured with kde-systemsettings. That's right that it's ignoring qt6ct but that wrong that it can only be configured with systemsettings. It rather can only be configured with a portal which should be implemented by your DE (i.e. your DE should have light/dark theme switch and KDE apps should automatically respect it choosing either Breeze Light or Breeze Dark). If your DE doesn't have such a feature or you're not using a DE then you can use darkman to set light/dark preference. Additionally, there's a way for QPAs to integrate with the kcolorscheme framework. Upstream qt6ct doesn't implement it but qt6ct-kde implements but only when you select a compatible color scheme (the ones marked as `(KColorScheme)`). > why does kate load ~/.config/qt6ct/colors/Darkgrey.conf but then does nothing with it? It works by Qt's plugin functionally which can load any third party code. Qt loads qt6ct code that reads it but then kcolorscheme framework overrides it with a compatible color scheme. > Surely this cannot be intended behavior as a feature and has to be a bug? And if it be intended, it seems like removing a useful feature that was their prior. It's intended, yeah. There was a long standing problem that KDE applications look weird outside of KDE (e.g. being half-light, half-dark at the same time). That's because KDE apps partially use Qt's QPalette while partially its own KColorScheme format which has more colors than QPalette. Now the framework forcefully overrides Qt's palette to one of the standard KColorSchemes (Breeze Light/Dark) unless the plugin (such as the kde one or qt6ct) sets a compatible color scheme (a KColorScheme).
(In reply to Ilya Fedin from comment #23) Well, you can obviously do what you want with your own project but this is an extreme loss of functionality for many I'd assume. My issue isn't “light or dark theme” which I can select myself. I have it on Breeze Dark now, but being able to select my own theme and colors which I made with qt6ct which is also able to load many other themes, not just colors aside. It worked perfectly well in the past and looked great on my system, so could you at least point me to the specific commit or revision in the specific framework or Kate itself that made this change of forcing it so I can at least manually patch and undo it for my own use as a temporary stopgap until I figure out what else to do? Also, is there a specific changelog release note somewhere that documents the exact qualities of this change?
(In reply to Ilya Fedin from comment #23) > It's intended, yeah. There was a long standing problem that KDE applications > look weird outside of KDE (e.g. being half-light, half-dark at the same > time). That's because KDE apps partially use Qt's QPalette while partially > its own KColorScheme format which has more colors than QPalette. Now the > framework forcefully overrides Qt's palette to one of the standard > KColorSchemes (Breeze Light/Dark) unless the plugin (such as the kde one or > qt6ct) sets a compatible color scheme (a KColorScheme). Nevermind that other comment, I misunderstood what this part meant but I'm still met with something I don't understand. Digging around on the web, I needed to install kvantum to make all the kcolorscheme themes appear in qt6ct and kate which they do. I now have a lot of KColorscheme themes in either and if I select either a specific one in Kate, or select “default” in kate and a specific one of the available ones in qt6ct-kde it selects the colorscheme I want, so far so good. However, when I make a copy of one of the default themes to edit to my liking, this copy firstly does not appear in the list of “window color schemes” in Kate, and secondly, if I select it in qt6ct-kde and use “default” in Kate, it uses Breeze Light again. I assume this is not intended behavior and that it should see it since it's a kcolorscheme now. I indeed opened up the file to look at it at it's path and it does look very different inside with far more specifics to it.
Right, qt6ct-kde is unable to edit KColorSchemes, currently only systemsettings app is able to do that. That's what I was telling you before. qt6ct-kde is my personal patchset, I haven't had a need in editing so I haven't implemented it...
(In reply to Ilya Fedin from comment #26) > Right, qt6ct-kde is unable to edit KColorSchemes, currently only > systemsettings app is able to do that. That's what I was telling you before. > > qt6ct-kde is my personal patchset, I haven't had a need in editing so I > haven't implemented it... Right sorry. I have it working now to satisfaction. In case anyone else later stumbles upon this. It's as simple as copying any of the files in /usr/share/color-schemes that get installed with kvantum to ~/.local/share/color-schemes and editing it by hand. These can now be selected by qt6ct-kde as default at which point kate picks it up.
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.
Got it working too with `qt6ct-kde`, thanks Ilya Fedin! The upstream `qt6ct` was archived and your branch seems to be the only working one...Can it somehow be made the source of the official repositories?
I tried to contact Arch but they don't want to do it. https://gitlab.archlinux.org/archlinux/packaging/packages/qt6ct/-/issues/1 It also seems the repository is archived not at author's will but due to account suspension which happened due to the sanctions as author works for a Russian military contractor, the company making Astra Linux. qt5ct on sourceforge has got a new release. Perhaps someone should contact the author about the new upstream URL.
New qt6ct upstream URL found https://www.opencode.net/trialuser/qt6ct
Awesome! I hope your PR gets merged soon
I have a feel qt6ct author is going to ignore it again. He ignored it for half a year before github suspended his account.