https://bugs.kde.org/show_bug.cgi?id=351055
--- Comment #24 from Thomas Lübking <thomas.luebk...@gmail.com> --- (In reply to andydecleyre from comment #23) > I thought you were saying that works for pinned programs/taskbars, because > those are already associated with the .desktop launchers. The switchwindow Uses exactly the same source as the taskbar. > The functional way is already code that's part of the project. plasmashell != kwin - it would be kinda sick to load the entire application database into the window manager because some clients set unwanted icons (and then prefer the static icon over the actual one) > In your ideal way, would you have to restart each application after changing > the icon theme, No, the client updates its icons (when it receives such trigger) and exports that information on the window. And restarting won't help - the problem is that eg. firefox loads its icon from the hicolor theme unconditionally (though on your side it even seems to be from /usr/lib/firefox/browser/chrome/icons/default ...) instead of respecting the theme configured for the desktop. > perfectly on the user-facing level should be preferred It's not. What you demand is to prefer a static icon that is mentioned in a desktop service that may or may not belong to this window over the icon that the client explicitly chose. A *possible* sane solution is to have the clients provide a link to their desktop service (see comment #9) and *only* specify actual icons (on top) if they want to replace that. However, for clients that wish to provide overlays on their icons (eg. to indicate the playing state or whatever) that's neither a solution and they will just have to do the pretty straight forward thing to simply read the icon from the theme that's configured for the present desktop. -- You are receiving this mail because: You are watching all bug changes.
