Created attachment 130900 [details] screenshot STEPS TO REPRODUCE 1. open your apps laucnher and search for some KCM, let's say Global Theme 2. right-click on "global theme" search result and choose "Add to desktop" 3. launch Global Theme kcm via its icon created on desktop OBSERVED RESULT As we can see in the attached screenshot, the window decoration of the launched KCM has Wayland generic icon. Task switcher (alt+tab) shows the same icon. EXPECTED RESULT Window decoration and task switcher should show the same icon observed in the task manager. SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.19.80 KDE Frameworks Version: 5.74.0 Qt Version: 5.14.2
Can confirm, but lowering priority now that most KCMs open in System Settings.
Currently this issue affects KCMs not present in System Settings, like Plasma Renderer and Trash. Operating System: Arch Linux KDE Plasma Version: 5.20.90 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2
*** Bug 437513 has been marked as a duplicate of this bug. ***
kcmshell tries to set an icon, but that only works on X11, not Wayland. It boils down to QDialog d; d.setWindowIcon(QIcon::fromTheme("cuttlefish")); d.show(); not working on Wayland
Just don't use kcmshell5. From Plasma 5.23 there's plasma-open-settings which will launch system settings (or plasma-settings if that's what you have) that works better on many levels. This issue isn't realistically fixable on Wayland.
It's not realistic to make QDialog::setWindowIcon() work on Wayland?
Well, the short answer (besides "no") is "it's not fixable under xdg-shell", as what we use to display the icon is the desktop file. Well we could make it show a random icon, surely not the kcm's.
I believe you, but it kind of boggles my mind that such a thing is unfixable by design. It would seem to point to a faulty design somewhere...
we could have kcms install themselves as applications, then kwin would find it I guess? The way KWin figures out the icon is by getting a desktop file (e.g. "firefox.desktop") then looking it up and using the Icon field within. We'd need to specify the desktop file for the KCM I guess and make sure it's in a place that KWin can find it.
Don't KCMs already have .desktop files?
Those are not installed into /usr/share/applications though
Is there a good reason not to? I guess if we did that they would show up in Kickoff etc, so maybe that's the reason. Is there a "hidden" flag or something we could set to make that not happen, yet still let them be seen by KWin?
Feels like a big detour. As a general rule, kcms are opened with system settings and we don't have a problem with that. In fact, why is this not a problem for systemsettings? Would showing the systemsettings icons here solve the problem?
Yeah that would probably be fine. KCMs opened in KCMshell are rare now anyway. Hence the "LO minor" importance level, I guess. :)
Turns out I was quite wrong in my assessment. On the bright side, it's fixed with the following MR.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1370
Git commit 73279acc63f72d36b8040e614fa489b7dcbfe127 by Aleix Pol Gonzalez, on behalf of Aleix Pol. Committed on 06/09/2021 at 11:48. Pushed by apol into branch 'master'. Fix absolute desktop file names Qt understands that the spec wants the id without .desktop postfix and chops it, so we need to add it back if we want to infer the desktop file. https://code.qt.io/cgit/qt/qtwayland.git/tree/src/client/qwaylandwindow.cpp?h=5.15#n161 M +7 -2 src/abstract_client.cpp https://invent.kde.org/plasma/kwin/commit/73279acc63f72d36b8040e614fa489b7dcbfe127
Can reproduce again on neon unstable. Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.23.80 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.3 Graphics Platform: Wayland
Cannot reproduce on Arch (Plasma 5.24 beta) and neon unstable.