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.

Reply via email to