https://bugs.kde.org/show_bug.cgi?id=369658
--- Comment #44 from David Faure <fa...@kde.org> --- (In reply to Eike Hein from comment #4) > * 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) That could be fixed by having specific API for an app to set the window icon, i.e. it wouldn't be done by most applications, only by those that really need it (like a webbrowser, which can have many windows open that need to be distinguished). Many other apps either show very few windows (korganizer, zanshin), or have no way to distinguish windows with icons anyway (kmail, kwrite, konsole). And for these I totally understand the consistency argument, but that's forgetting the webbrowser use case, see the screenshots like "Happy guessing..." in this report. > * 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) Same reasoning here, same solution. > * 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 Ditto. Legacy apps wouldn't be using this new API. > * 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 What plasma developers don't seem to understand is that 99% of the users are using X11, not wayland... As long as my system runs X11, I don't really care what wayland's limitations are. If wayland is designed in a way that breaks this use case, then that's a wayland bug. > * 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 That's developer reasoning, which shouldn't outweigh usability ;) -- You are receiving this mail because: You are watching all bug changes.
