Summary: | On Wayland, the color scheme of gtk3 apps is not fully updated when changing global themes in Global Theme KCM (Quick Settings and Colors KCMs are unaffected) | ||
---|---|---|---|
Product: | [Applications] systemsettings | Reporter: | Patrick Silva <bugseforuns> |
Component: | kcm_lookandfeel | Assignee: | medin <med.medin.2014> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | 4wy78uwh, agrinev98, antonioni.rocha, arealperson1234+kde, damikope, dev.bacteriostat, ferenosdev, filippo27998, kde, kdedev, m.weghorn, mail, med.medin.2014, michal.dybczak, mohan.ram, nate, peter, pieterkristensen, postix, qydwhotmail, samuelsumukhreddy, seqularise, uhhadd, wachidadinugroho.maya |
Priority: | NOR | Keywords: | wayland |
Version: | 5.27.4 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/plasma/kde-gtk-config/-/commit/8d929fc86396ce28c8f89b35ef1eeeed9ef3591d | Version Fixed In: | |
Sentry Crash Report: | |||
Attachments: |
Firefox and Thunderbird not applying gtk theme
Changing global theme |
Description
Patrick Silva
2020-05-18 21:36:16 UTC
I found a "solution" to this on reddit, restart the gtk settings service in plasma and then restart gtk application, it will get the new color scheme. A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/55 Git commit 755e546019b5a9e82652ed5b5d10cd5b75340361 by Nate Graham, on behalf of Mikhail Zolotukhin. Committed on 07/07/2020 at 23:27. Pushed by ngraham into branch 'master'. Notify about changes when changing Global Theme This is needed for GTK Daemon to correctly change various GTK settings as well (e.g. icon theme, colors, etc). M +6 -6 kcms/lookandfeel/kcm.cpp https://invent.kde.org/plasma/plasma-desktop/commit/755e546019b5a9e82652ed5b5d10cd5b75340361 Git commit 24211d51b223c1bb30a86f2c83a2331022dc8b69 by Nate Graham, on behalf of Mikhail Zolotukhin. Committed on 07/07/2020 at 23:28. Pushed by ngraham into branch 'Plasma/5.19'. Notify about changes when changing Global Theme This is needed for GTK Daemon to correctly change various GTK settings as well (e.g. icon theme, colors, etc). (cherry picked from commit 755e546019b5a9e82652ed5b5d10cd5b75340361) M +6 -6 kcms/lookandfeel/kcm.cpp https://invent.kde.org/plasma/plasma-desktop/commit/24211d51b223c1bb30a86f2c83a2331022dc8b69 This bug is still reproducible even with a new user account after update to Plasma 5.19.4 and reboot. Operating System: Arch Linux KDE Plasma Version: 5.19.4 KDE Frameworks Version: 5.72.0 Qt Version: 5.15.0 For me colors are changing partially, when changing global theme. No idea why this happens, so I can't really fix it. Thank you for your effort anyway Mikhail. :) I can confirm this over here on KDE neon as well. *** Bug 426727 has been marked as a duplicate of this bug. *** *** Bug 429129 has been marked as a duplicate of this bug. *** A possibly relevant merge request was started @ https://invent.kde.org/plasma/kde-gtk-config/-/merge_requests/23 Git commit a197df2c71c5160e87f14bb09e35b53b116b1a41 by David Redondo. Committed on 28/01/2021 at 11:13. Pushed by davidre into branch 'master'. Use the same configs for watching and reading KColorScheme uses KSharedConfig::openConfig() when no config is specified, we were watching a KSharedConfig::openConfig("kdeglobals") which seemingly is not updated instantly because it technically is different even though effectively it's the same config. Watching the same configs solves the theme not updating when the global theme is switched FIXED-IN:5.21 M +1 -1 kded/configvalueprovider.cpp M +1 -1 kded/gtkconfig.cpp https://invent.kde.org/plasma/kde-gtk-config/commit/a197df2c71c5160e87f14bb09e35b53b116b1a41 Git commit 7e61802bb179f53e0e785109ce7ab35d9b5dec54 by David Redondo. Committed on 28/01/2021 at 11:33. Pushed by davidre into branch 'Plasma/5.21'. Use the same configs for watching and reading KColorScheme uses KSharedConfig::openConfig() when no config is specified, we were watching a KSharedConfig::openConfig("kdeglobals") which seemingly is not updated instantly because it technically is different even though effectively it's the same config. Watching the same configs solves the theme not updating when the global theme is switched FIXED-IN:5.21 (cherry picked from commit a197df2c71c5160e87f14bb09e35b53b116b1a41) M +1 -1 kded/configvalueprovider.cpp M +1 -1 kded/gtkconfig.cpp https://invent.kde.org/plasma/kde-gtk-config/commit/7e61802bb179f53e0e785109ce7ab35d9b5dec54 Can reproduce this bug again on neon unstable. Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.22.80 KDE Frameworks Version: 5.84.0 Qt Version: 5.15.3 Graphics Platform: X11 *** Bug 444027 has been marked as a duplicate of this bug. *** Also on Neon User Edition I have exactly this experience. Thunderbird and Firefox both do not follow changes in the color scheme. In my experience it's best to wipe the ~/.config/gtk-3.0 and ~/.config/gtk-4.0 folders then choose the new color scheme and then immediately after that reboot. Operating System: KDE neon 5.23 KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.89.0 Qt Version: 5.15.3 Kernel Version: 5.11.0-46-generic (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Celeron® J4105 CPU @ 1.50GHz Memory: 7.4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 600 To elaborate a little about comment 16... I switched from the Lightly application theme to Breeze (Evolution) because I liked it so much. Since then changing colors and also global themes is broken between qt and gtk apps. As an experiment I re-installed the Lightly theme and changed colors and global themes to see what Thunderbird and Firefox would do. They reacted completely as they should! In am no more than an enthusiastic KDE user but my guess is that the fact that this bug came back has to do with the introduction of the new Breeze theme... *** Bug 451367 has been marked as a duplicate of this bug. *** This affects the Global Themes KCM as well as the Quick Settings page which does the same thing. *** Bug 448044 has been marked as a duplicate of this bug. *** *** Bug 417463 has been marked as a duplicate of this bug. *** *** Bug 438182 has been marked as a duplicate of this bug. *** I can still reproduce on 5.25.4: Operating System: Fedora Linux 36 KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 Kernel Version: 5.17.5-300.fc36.x86_64 (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i5-2520M CPU @ 2.50GHz Memory: 7.7 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 3000 > This affects the Global Themes KCM as well as the Quick Settings page which does the same thing.
Probably misses writing with Notify
Actually cannot reproduce, firefox changes color instantly when using the global theme kcm (In reply to David Redondo from comment #25) > Actually cannot reproduce, firefox changes color instantly when using the global theme kcm Firefox 102 works fine for me too. However, in case of other GTK apps such as Thunderbird, Gajim, Dino for instance, only the color of the (non CSD) title bar changes on changing the global theme. The rest of the UI first change when setting a different GTK theme under "Configure Application Style --> GNOME/GTK Application Style". I'm on Plasma 5.25.3 (openSUSE TW) (In reply to David Redondo from comment #25) > Actually cannot reproduce, firefox changes color instantly when using the > global theme kcm I am not sure, but I seem to recall Firefox is actually picking up on the "dark/light mode" standard now (as in Freedesktop standard), and adjusting itself to its value, so that may be why it is not affected (just a theory though). Hmm yes gedit doesn't change while it works from colors kcm. (In reply to KDamian from comment #27) > (In reply to David Redondo from comment #25) > > Actually cannot reproduce, firefox changes color instantly when using the > > global theme kcm > > I am not sure, but I seem to recall Firefox is actually picking up on the > "dark/light mode" standard now (as in Freedesktop standard), and adjusting > itself to its value, so that may be why it is not affected (just a theory > though). Sorry, I misremembered the chain of messages, feel free to ignore my previous comment. :) A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1961 Git commit 9a77503f0bd9ce0ccd0e99c08e9feef76c99743a by David Redondo. Committed on 10/08/2022 at 14:18. Pushed by davidre into branch 'master'. lookandfeelmanager: Write colors before color scheme While we indeed write both with KConfig::Notify flag interested processes might only listen to the scheme change instead of every color scheme group. When they react to the scheme change the colors have not yet changed. The colors kcm also does it in this order. FIXED-IN:5.24.7 M +2 -1 kcms/lookandfeel/lookandfeelmanager.cpp https://invent.kde.org/plasma/plasma-workspace/commit/9a77503f0bd9ce0ccd0e99c08e9feef76c99743a Git commit 864b2b7797ad8ad22a5eb3c90534b80ca1655d4c by David Redondo. Committed on 10/08/2022 at 15:05. Pushed by davidre into branch 'Plasma/5.25'. lookandfeelmanager: Write colors before color scheme While we indeed write both with KConfig::Notify flag interested processes might only listen to the scheme change instead of every color scheme group. When they react to the scheme change the colors have not yet changed. The colors kcm also does it in this order. FIXED-IN:5.24.7 (cherry picked from commit 9a77503f0bd9ce0ccd0e99c08e9feef76c99743a) M +2 -1 kcms/lookandfeel/lookandfeelmanager.cpp https://invent.kde.org/plasma/plasma-workspace/commit/864b2b7797ad8ad22a5eb3c90534b80ca1655d4c Git commit 376c74f582a41a8e0eec7c4443d8b7401be97f0d by David Redondo. Committed on 10/08/2022 at 15:07. Pushed by davidre into branch 'Plasma/5.24'. lookandfeelmanager: Write colors before color scheme While we indeed write both with KConfig::Notify flag interested processes might only listen to the scheme change instead of every color scheme group. When they react to the scheme change the colors have not yet changed. The colors kcm also does it in this order. FIXED-IN:5.24.7 (cherry picked from commit 9a77503f0bd9ce0ccd0e99c08e9feef76c99743a) M +2 -1 kcms/lookandfeel/lookandfeelmanager.cpp https://invent.kde.org/plasma/plasma-workspace/commit/376c74f582a41a8e0eec7c4443d8b7401be97f0d This bug is still reproducible with the steps provided in comment 0. Tested even with a new user account. Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.25.80 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.5 Graphics Platform: Wayland Can reproduce. Works for me with todays KDE neon unstable and gedit Can still reproduce on Plasma 5.25.5. Tested on Firefox and Virt-Manager. *** Bug 460359 has been marked as a duplicate of this bug. *** Doesn't works on Wayland but it's works on X11 Plasma 5.26.0 Frameworks 5.99.0 Can confirm that. A possibly relevant merge request was started @ https://invent.kde.org/plasma/kde-gtk-config/-/merge_requests/73 Git commit 5f75f4c94d5fc07cc3dd9b36c78a297f3135feae by Fushan Wen. Committed on 30/03/2023 at 00:17. Pushed by fusionfuture into branch 'Plasma/5.27'. kded: provide `org.gtk.Settings` when `GTK_USE_PORTAL` is not set on Wayland A number of things that gnome-settings-daemon monitors for all the GTK+ applications aren't currently available for GTK+ Wayland clients, only through XSettings. As we already monitor fontconfig configurations, enabled GTK+ modules and whether applications should use animations, export those through a D-Bus interface. See https://bugzilla.gnome.org/show_bug.cgi?id=786693 Based on patch by Martin Blanchard <tchaik@gmx.com> https://bugzilla.gnome.org/show_bug.cgi?id=786694 Upstream change: https://github.com/GNOME/gnome-settings-daemon/commit/522640a6df95312669871e4f881afe4e37e495f9 FIXED-IN: 5.27.4 A +9 -0 .reuse/dep5 M +15 -2 kded/CMakeLists.txt A +76 -0 kded/gsd-xsettings-manager/gsd-xsettings-manager.cpp [License: GPL(v2.0+)] A +32 -0 kded/gsd-xsettings-manager/gsd-xsettings-manager.h [License: GPL(v2.0+)] A +7 -0 kded/gsd-xsettings-manager/org.gtk.Settings.xml M +11 -0 kded/gtkconfig.cpp M +4 -0 kded/gtkconfig.h https://invent.kde.org/plasma/kde-gtk-config/commit/5f75f4c94d5fc07cc3dd9b36c78a297f3135feae Git commit 1608cf03670c71d85f110a7d2dda1c576e939032 by Fushan Wen. Committed on 30/03/2023 at 00:21. Pushed by fusionfuture into branch 'master'. kded: provide `org.gtk.Settings` when `GTK_USE_PORTAL` is not set on Wayland A number of things that gnome-settings-daemon monitors for all the GTK+ applications aren't currently available for GTK+ Wayland clients, only through XSettings. As we already monitor fontconfig configurations, enabled GTK+ modules and whether applications should use animations, export those through a D-Bus interface. See https://bugzilla.gnome.org/show_bug.cgi?id=786693 Based on patch by Martin Blanchard <tchaik@gmx.com> https://bugzilla.gnome.org/show_bug.cgi?id=786694 Upstream change: https://github.com/GNOME/gnome-settings-daemon/commit/522640a6df95312669871e4f881afe4e37e495f9 FIXED-IN: 5.27.4 (cherry picked from commit 5f75f4c94d5fc07cc3dd9b36c78a297f3135feae) A +9 -0 .reuse/dep5 M +15 -2 kded/CMakeLists.txt A +76 -0 kded/gsd-xsettings-manager/gsd-xsettings-manager.cpp [License: GPL(v2.0+)] A +32 -0 kded/gsd-xsettings-manager/gsd-xsettings-manager.h [License: GPL(v2.0+)] A +7 -0 kded/gsd-xsettings-manager/org.gtk.Settings.xml M +11 -0 kded/gtkconfig.cpp M +4 -0 kded/gtkconfig.h https://invent.kde.org/plasma/kde-gtk-config/commit/1608cf03670c71d85f110a7d2dda1c576e939032 Cannot reproduce with some apps, but can with others. Not affected apps: Nautilus Gnome Disks Affected apps: Gedit Deluge torrent client Brasero cd/dvd/bd burner pamac package manager streps to reproduce: 1. start Plasma session with Brezze global theme 2. change global theme to Breeze Dark 3. revert the global theme to Breeze 4. open any affected app mentioned above Result: global theme is Breeze but the color scheme of the affected apps is Breeze Dark. Logout and login fixes the affected apps. Operating System: Arch Linux KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Graphics Platform: Wayland For me, the GTK color settings aren't applied the first time after I open a application if I use the plasma-apply-colorscheme command line tool (both when using it directly or invoking it from scripts). They will be applied at all subsequent times, and will be applied if the color scheme is changed from System Settings. Firefox also does not apply the color scheme correctly the first time even if using System Settings, appearing to use the Adwaita theme, but will apply it correctly at subsequent times. Chromium appears to require restarting to apply any color scheme correctly. The end result is that currently theme switching automated via scripting remains mostly broken in GTK applications on Wayland. A possibly relevant merge request was started @ https://invent.kde.org/plasma/kde-gtk-config/-/merge_requests/78 Git commit 90b423429dde264117c729d5455e581ebb09a109 by Fushan Wen. Committed on 08/04/2023 at 08:37. Pushed by fusionfuture into branch 'Plasma/5.27'. kded: add explicit waiting time before setting colors modulesChanged signal will take some time to reach a GTK3 app, so wait a moment before "colorreload-gtk-module" is finally loaded into GTK3 apps. This makes sure color schemes in GTK3 apps are updated as expected. This may not be a problem after https://gitlab.gnome.org/GNOME/gtk/-/commit/a40126e1f91a0cc8c45203d9ff229f65952eb541 is merged, but if the module list does not contain the expected module, users will still notice color schemes are not changed in GTK3 apps for the first time users change the system color scheme. M +16 -16 kded/config_editor/custom_css.cpp M +8 -0 kded/config_editor/custom_css.h M +7 -2 kded/gtkconfig.cpp https://invent.kde.org/plasma/kde-gtk-config/commit/90b423429dde264117c729d5455e581ebb09a109 A possibly relevant merge request was started @ https://invent.kde.org/plasma/kde-gtk-config/-/merge_requests/79 Git commit d49e02cf4bb1052e8b3c593c389d0a563abe00f8 by Fushan Wen. Committed on 10/04/2023 at 00:51. Pushed by fusionfuture into branch 'master'. kded: add explicit waiting time before setting colors modulesChanged signal will take some time to reach a GTK3 app, so wait a moment before "colorreload-gtk-module" is finally loaded into GTK3 apps. This makes sure color schemes in GTK3 apps are updated as expected. This may not be a problem after https://gitlab.gnome.org/GNOME/gtk/-/commit/a40126e1f91a0cc8c45203d9ff229f65952eb541 is merged, but if the module list does not contain the expected module, users will still notice color schemes are not changed in GTK3 apps for the first time users change the system color scheme. (cherry picked from commit 90b423429dde264117c729d5455e581ebb09a109) M +16 -16 kded/config_editor/custom_css.cpp M +8 -0 kded/config_editor/custom_css.h M +7 -2 kded/gtkconfig.cpp https://invent.kde.org/plasma/kde-gtk-config/commit/d49e02cf4bb1052e8b3c593c389d0a563abe00f8 Please note GTK4 apps are not possible to change their color schemes wihtout a restart, and if you set `GTK_USE_PORTAL=1`, you will still need to restart a GTK3 app to get the new color scheme. This is not a bug in Plasma but a limitation in GTK3/4. Make sure you have unset `GTK_USE_PORTAL` before reporting bugs. (In reply to Fushan Wen from comment #50) > Please note GTK4 apps are not possible to change their color schemes wihtout a restart Is this an absolute statement or are there exceptions? For instance the color scheme of the GTK4 application `Dino 0.4.2` can be instantaneously changed by executing [1] under Plasma 5.27.4 Wayland > gsettings set org.gnome.desktop.interface color-scheme 'prefer-dark' [1] https://github.com/dino/dino/wiki/Frequently-asked-questions-(FAQ)#how-to-set-a-dark-theme (In reply to postix from comment #51) > Is this an absolute statement or are there exceptions? I believe there are no exceptions. You can try different accent colors to see if the color in Dino is updated. (In reply to Fushan Wen from comment #52) > I believe there are no exceptions. You can try different accent colors to > see if the color in Dino is updated. Never mind, looks like it's just about the dark/light theme variant, see [1][2], which can be changed instantaneously for GTK4 apps. [1] https://wiki.archlinux.org/title/Dark_mode_switching#gsettings [2] https://wiki.archlinux.org/title/Dark_mode_switching#KDE (In reply to postix from comment #53) > (In reply to Fushan Wen from comment #52) > > I believe there are no exceptions. You can try different accent colors to > > see if the color in Dino is updated. > > Never mind, looks like it's just about the dark/light theme variant, see > [1][2], which can be changed instantaneously for GTK4 apps. > > [1] https://wiki.archlinux.org/title/Dark_mode_switching#gsettings > [2] https://wiki.archlinux.org/title/Dark_mode_switching#KDE Dino is not a traditional GTK4 app. It uses libadwaita, which supports XDG color scheme. Unfortunately this bug is still reproducible with the steps from comment 44. Operating System: Arch Linux KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Graphics Platform: Wayland Can anybody else reproduce? Also make sure you have not set `GTK_USE_PORTAL` otherwise the fix won't work. GTK_USE_PORTAL is not set on my system. $ env|grep GTK GTK_RC_FILES=/etc/gtk/gtkrc:/home/stalker/.gtkrc:/home/stalker/.config/gtkrc GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/stalker/.gtkrc-2.0:/home/stalker/.config/gtkrc-2.0 GTK_OVERLAY_SCROLLING=0 Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! On 5.27.5, the situation is really messy and chaotic, if I change global theme from Breeze Light to Breeze Dark, only Firefox and Thunderbird change to a dark theme but not the Breeze one, both switch to Dark Adwaita (even if in Application Style > GTK settings I see Breeze applied), other GTK apps like UGet and Pamac don't update their theme and sometimes even after restarting them they remain using Light Breeze, the only solution I found in that special case is to change Color scheme to Breeze Light then switch to Breeze Black (sometimes needed to be done two times) which seems to fix Pamac and UGet and force them to use Breeze Dark theme. Patrick, have you installed xdg-desktop-portal-gnome ? One may need xdg-desktop-portal-gnome to make it work. (In reply to medin from comment #59) > On 5.27.5, the situation is really messy and chaotic, if I change global > theme from Breeze Light to Breeze Dark, only Firefox and Thunderbird change > to a dark theme but not the Breeze one, both switch to Dark Adwaita (even if > in Application Style > GTK settings I see Breeze applied), other GTK apps > like UGet and Pamac don't update their theme and sometimes even after > restarting them they remain using Light Breeze, the only solution I found in > that special case is to change Color scheme to Breeze Light then switch to > Breeze Black (sometimes needed to be done two times) which seems to fix > Pamac and UGet and force them to use Breeze Dark theme. This doesn't look like the same bug but corrupted config files. (In reply to Fushan Wen from comment #61) > This doesn't look like the same bug but corrupted config files. No corruption can happen, because GTK2, GTK3 and GTK4 config files are fully updated via Plasma system settings after applying any global theme. (In reply to Fushan Wen from comment #60) > Patrick, have you installed xdg-desktop-portal-gnome ? One may need > xdg-desktop-portal-gnome to make it work. yes, xdg-desktop-portal-gnome package is installed on my system. That looks unfortunate. I cannot even reproduce the bug with a new user, so something must be wrong elsewhere. (In reply to Fushan Wen from comment #61) > (In reply to medin from comment #59) > > On 5.27.5, the situation is really messy and chaotic, if I change global > > theme from Breeze Light to Breeze Dark, only Firefox and Thunderbird change > > to a dark theme but not the Breeze one, both switch to Dark Adwaita (even if > > in Application Style > GTK settings I see Breeze applied), other GTK apps > > like UGet and Pamac don't update their theme and sometimes even after > > restarting them they remain using Light Breeze, the only solution I found in > > that special case is to change Color scheme to Breeze Light then switch to > > Breeze Black (sometimes needed to be done two times) which seems to fix > > Pamac and UGet and force them to use Breeze Dark theme. > > This doesn't look like the same bug but corrupted config files. I get the same though. Firefox just switches to the dark version of the default GTK theme when I switch from Breeze Light to Breeze Dark. (In reply to Fushan Wen from comment #61) > This doesn't look like the same bug but corrupted config files. Another scenario is happening here, after setting a new user, it seems to be working for first tries, except for Firefox and Thunderbird that reset their theme to Adwaita instead of using Breeze. But after the first crash of Plasma settings during changing global themes, then this fix stopped working and GTK3 apps refuse to follow global theme even if you restart them. (In reply to Fushan Wen from comment #56) > Can anybody else reproduce? Also make sure you have not set `GTK_USE_PORTAL` > otherwise the fix won't work. Truthfully, unsetting GTK_USE_PORTAL to have this fix (even if it doesn't work for now) have much more severe problems than forcing color scheme and simply restarting the app. Because all GTK apps will start using that ugly GTK file picker instead of KDE dialogs. (In reply to medin from comment #67) > (In reply to Fushan Wen from comment #56) > > Can anybody else reproduce? Also make sure you have not set `GTK_USE_PORTAL` > > otherwise the fix won't work. > > Truthfully, unsetting GTK_USE_PORTAL to have this fix (even if it doesn't > work for now) have much more severe problems than forcing color scheme and > simply restarting the app. Because all GTK apps will start using that ugly > GTK file picker instead of KDE dialogs. Contrary to intuition, setting GTK_USE_PORTAL=1 in a non-portal environment will cause many unintentional bugs in GTK apps. GTK has added some workarounds to avoid them. (In reply to third="Beedell", first="Roke", second="Julian Lockhart" from comment #65) > (In reply to Fushan Wen from comment #61) > > (In reply to medin from comment #59) > > > On 5.27.5, the situation is really messy and chaotic, if I change global > > > theme from Breeze Light to Breeze Dark, only Firefox and Thunderbird change > > > to a dark theme but not the Breeze one, both switch to Dark Adwaita (even if > > > in Application Style > GTK settings I see Breeze applied), other GTK apps > > > like UGet and Pamac don't update their theme and sometimes even after > > > restarting them they remain using Light Breeze, the only solution I found in > > > that special case is to change Color scheme to Breeze Light then switch to > > > Breeze Black (sometimes needed to be done two times) which seems to fix > > > Pamac and UGet and force them to use Breeze Dark theme. > > > > This doesn't look like the same bug but corrupted config files. > > I get the same though. Firefox just switches to the dark version of the > default GTK theme when I switch from Breeze Light to Breeze Dark. That is a different bug. Please either open a new bug or report it to Firefox. I just downloaded the latest Fedora KDE (0615) and KDE Neon (0622), tried to reproduce the bug in the two Live environments, but still cannot reproduce it. I consider this bug as fixed, and now it's a packaging issue that causes the bug. Please report the issue to your distro. Thanks! For anyone suffering from this problem on Arch based distros, simply go to Plasma settings then select "Startup and Shutdown" then "Background Services", locate "GNOME/GTK Settings Synchronization Service" and stop it then restart it to get the applied global theme to propagate to all running GTK+ apps without needing to restart them. Well, I have just downloaded neon-user-20230622-0716.iso, created a bootable flash drive with it, and I can reproduce the bug with gedit and brasero following the steps from comment 44. I have just noticed something very important on both Arch and neon: the bug occurs after changing the global theme via Global Theme KCM, but it does not when doing it via Quick Settings page. streps to reproduce: 1. start Plasma session with Breeze global theme 2. open System Settings > Appearance > Global Theme KCM 3. change global theme to Breeze Dark 4. revert the global theme to Breeze 5. open gedit or brasero Result: the app used in the last step uses dark color scheme instead of breeze color scheme. Can you reproduce Fushan? Can reproduce. Let's move the bug to Global Theme. (In reply to Fushan Wen from comment #68) > Contrary to intuition, setting GTK_USE_PORTAL=1 in a non-portal environment > will cause many unintentional bugs in GTK apps. GTK has added some > workarounds to avoid them. Well, changing the global theme is done once in months so rebooting to fix it seems fine for me, while removing GTK_USE_PORTAL=1 will force all GTK apps to use their GTK file/folder selector which will break the uniform look of file selectors in Plasma desktop, and most importantly is that file/folder selector is used many times per day compared to the frequency of changing the global theme. A possibly relevant merge request was started @ https://invent.kde.org/plasma/kde-gtk-config/-/merge_requests/100 Promoting this to be a 15-minute bug since it's Wayland-only and the Wayland-session is the default in Plasma 6 now. I noticed this bug just now in Plasma 6.0.2, because I wasn't using global themes much before. Basically, after updating to Plasma 6, I switched to Breeze Dark. I was changing a lot of things after the update, so I didn't notice that gtk3 theme was not following, I was applying it manually later anyway. Now, I switched to light theme using Breeze global theme. At first, I thought that LibreOffice (flatpack VCL gtk3) was bugged, because it wasn't following the system theme, so I attempted to debugging it, but some time later I noticed that Thunderbird, electron and other apps also were still dark themed. It turned out that GTK theme wasn't applied on Global Theme Breeze usage. Of course, I'm using Wayland (and was using it since over half a year). The bug is still there and can be confusing. With a new user on Plasma6.0.2, this problem became persistent, even if I restart that GNOME sync theme service, it doesn't work. Plus, Plasma style and icons in open/save dialogs sometimes keep using the ones from previously selected global theme, this was not present in Plasma 5.27.10. If you are using GTK_USE_PORTAL=1, it's expected the color is not synced on Wayland. (In reply to Fushan Wen from comment #80) Why? (In reply to Fushan Wen from comment #80) > If you are using GTK_USE_PORTAL=1, it's expected the color is not synced on > Wayland. Why was this bug closed ? Even without GTK_USE_PORTAL=1, automatic application of GTK theme is not working with Plasma 6.0.5. Because the bug has been fixed for a long time, other people can't reproduce it, and what you experience is likely caused by a misconfiguration of your distro. Please upload a video of the bug. Created attachment 170216 [details]
Firefox and Thunderbird not applying gtk theme
(In reply to Fushan Wen from comment #83) > Because the bug has been fixed for a long time, other people can't reproduce > it, and what you experience is likely caused by a misconfiguration of your > distro. Please upload a video of the bug. I attached a video showing the problem with Firefox and thunderbird. So that is a completely different bug, please open a new bug. Thanks! Created attachment 170217 [details]
Changing global theme
Sorry, I made an error and showed the wrong scenario :)
Can reproduce. I think it should be removed from the HI list as it only affects the lnf KCM. Setting colors in the color KCM is not affected. Lowering priority since this only affects the Global Themes KCM, and the number of GTK apps that even respond to our re-coloring in the first place is diminishing. :( A possibly relevant merge request was started @ https://invent.kde.org/plasma/kde-gtk-config/-/merge_requests/116 Git commit ffe400047ae4cd9836aff7f9a1795115edb738d0 by Michael Weghorn. Committed on 24/08/2024 at 10:50. Pushed by ngraham into branch 'master'. kded: Handle global theme change A "Global Theme" can include almost all of the visual appearance settings, so call `GtkConfig::applyAllSettings` to make sure all of them are in sync after being notified about a change of the global theme. M +4 -0 kded/gtkconfig.cpp https://invent.kde.org/plasma/kde-gtk-config/-/commit/ffe400047ae4cd9836aff7f9a1795115edb738d0 Git commit 8d929fc86396ce28c8f89b35ef1eeeed9ef3591d by Nate Graham. Committed on 27/08/2024 at 14:38. Pushed by ngraham into branch 'Plasma/6.1'. kded: Handle global theme change A "Global Theme" can include almost all of the visual appearance settings, so call `GtkConfig::applyAllSettings` to make sure all of them are in sync after being notified about a change of the global theme. (cherry picked from commit ffe400047ae4cd9836aff7f9a1795115edb738d0) Co-authored-by: Michael Weghorn <m.weghorn@posteo.de> M +4 -0 kded/gtkconfig.cpp https://invent.kde.org/plasma/kde-gtk-config/-/commit/8d929fc86396ce28c8f89b35ef1eeeed9ef3591d |