https://bugs.kde.org/show_bug.cgi?id=468129
--- Comment #4 from Wyatt Childers <kdebugs.81do7@haxing.ninja> --- (In reply to Nate Graham from comment #3) > The issue is that KWin is a window manager and gets its window icons from > the window. So the window has to *have* an icon for KWin to display. The > Task Manager, on the other hand looks in the app's desktop file to get the > icon. KWin theoretically could do this too, so you're not wrong that it's an > ideological stance on the part of the KWin developers. The thing is, always > using the .desktop file icon would mean that if the window did set its own > icon, KWin would discard it, ignoring the wishes of the developer. KWin > could do it only when the window doesn't set its own window icon, maybe. But > this could seem random to the user. I think it would be completely sensible to fallback to the desktop file when the application has not set an icon. If a window sets an icon that's great, and sure it should be used. However, if a window fails to set an icon, I think it's far more shocking that a "wayland" or "x11" icon is used, meanwhile KDE (as a whole) clearly sees a much more optimal answer provided by the desktop file. i.e., I'd argue the rule should be: 1. Use what the window set 2. Use what the desktop set 3. Use a fallback icon for Wayland/X11 (as a last resort) #2 is always going to be far more user relevant than #3. In terms of UX, I think the most compelling use case is that, as it stands, if this bug is exhibited by a handful of currently open applications the icon only task switcher is rendered borderline useless. -- You are receiving this mail because: You are watching all bug changes.
