https://bugs.kde.org/show_bug.cgi?id=369658
--- Comment #4 from Eike Hein <h...@kde.org> --- It's been discussed many times in the past, but here's the lowdown: * If we don't give precedence to the system icon for an app, it means the icon can change during a transition from launcher to window, which breaks the lifecycle visually and is upsetting to users (-> bug reports) * Ditto not respecting the user's choice in custom icon theme (app code may load icon assets differently from Plasma, so no consistency is guaranteed) or custom configured icon (menu editor) * Legacy apps often load icon assets in ways that doesn't give us a hi-res icon we need for hi-dpi systems, causing the icons to look blurry or pixelated * Wayland doesn't support window icons much less ones that change at runtime, so if this were optional we wouldn't be able to offer this option across windowing systems, further sacrificing consistency * The Task Manager is not a window list, the buttons it displays are an abstraction over several data sources (launchers, startup notifications, windows (some of which are logically treated as a single entity, e.g. in case of hidden utility windows, or grouping)) and the integrity of this abstraction outweighs providing detailed window metadata Bottom line: (a) Far more users expect/rely on apps in the Task Manager having a stable, recognizable icon (potentially one they explicitly chose) than on window-specific icons, (b) the quality of the window metadata is low and it's not consistently available across supported windowing systems. -- You are receiving this mail because: You are watching all bug changes.