Created attachment 186434 [details] Source code for a small Qt application (in C++) to demonstrate the issue. SUMMARY The bizarre bug manifests after switching from Breeze to other Qt styles (e.g. Fusion). This issue was previously reported to Qt in https://bugreports.qt.io/browse/QTBUG-141634 but, after some quick look at Breeze's source code, it appears that Breeze _may_ be the culprit. STEPS TO REPRODUCE 1. Start a Qt application (which would be using the Breeze style in Plasma). 2. Switch to Fusion (assuming the application permits the switch, like in the `qt-tool-bars.cpp` attached example). 3. Attempt to set the `QPalette::window` / `QPalette::base` color in the Qt application (again assuming the application offers this action). OBSERVED RESULT The top tool bar (if it exists in the application) shows a background color that matches that color that Breeze would use. EXPECTED RESULT The top tool bar color should use the customized color set in the application palette.
Created attachment 186439 [details] An animated GIF that shows that, after enabling the system style (Breeze), the background color in the top tool bar goes missing when other style (Fusion) is used.
It seems the problem is that `_listener` in `ToolsAreaManager` is never destroyed, therefore the tools area manager continues to operate even after a new `QStyle` has been set in the application. This piece of code is what appears to be modifying the tool bars: ```cpp if (window->toolBarArea(toolbar) == Qt::TopToolBarArea) { widget->setPalette(palette()); appendIfNotAlreadyExists(window, toolbar); return true; } ``` https://invent.kde.org/plasma/breeze/-/blob/e853447a8aaaa0ea0f04d0f43e05637272a4cbb6/kstyle/breezetoolsareamanager.cpp#L147-151 The potential fix would be: ```diff diff --git a/kstyle/breezetoolsareamanager.cpp b/kstyle/breezetoolsareamanager.cpp index f2aaec4..7254796 100644 --- a/kstyle/breezetoolsareamanager.cpp +++ b/kstyle/breezetoolsareamanager.cpp @@ -46,6 +46,7 @@ ToolsAreaManager::ToolsAreaManager() ToolsAreaManager::~ToolsAreaManager() { + delete _listener; } void ToolsAreaManager::loadSchemeConfig(const QString &path) ```
Would you be willing to make a merge request with the potential fix?
Merge request: https://invent.kde.org/plasma/breeze/-/merge_requests/560
A possibly relevant merge request was started @ https://invent.kde.org/plasma/breeze/-/merge_requests/561
Git commit 506ab0e13bcf35dcf07a464b1830067131891639 by Nicolas Fella. Committed on 10/11/2025 at 14:06. Pushed by nicolasfella into branch 'master'. [toolsareamanager] Reset palette on unpolish We modify the palette of the widget, so when we change style we should be polite and restore the palette, otherwise the change will persist M +11 -0 kstyle/breezetoolsareamanager.cpp https://invent.kde.org/plasma/breeze/-/commit/506ab0e13bcf35dcf07a464b1830067131891639
Git commit 3b00a0ee0e0b9cd6dc341e5811e3dc1451a18fc9 by Nicolas Fella. Committed on 10/11/2025 at 16:31. Pushed by nicolasfella into branch 'Plasma/6.5'. [toolsareamanager] Reset palette on unpolish We modify the palette of the widget, so when we change style we should be polite and restore the palette, otherwise the change will persist (cherry picked from commit 506ab0e13bcf35dcf07a464b1830067131891639) M +11 -0 kstyle/breezetoolsareamanager.cpp https://invent.kde.org/plasma/breeze/-/commit/3b00a0ee0e0b9cd6dc341e5811e3dc1451a18fc9