Bug 459735

> The panel displays a wrong icon, but the window switcher (alt+tab) displays the correct icon.
This is caused by a quirk on X11; the Task Manager icon uses the icon from the app's .desktop file, while the Task Switcher allows the window itself to define a custom icon, and if it does, it displays it. If it doesn't, then it falls back to the .desktop file.

For consistency's sake, we should probably stop doing this. We've gotten tons of bug reports over the years and I think allowing these icons to diverge more harm than good.

> and does not show an audio indicator if the application produces sound.
That's a different issue, and is most likely caused by the app not using PulseAudio or PipeWire to produce the sound. Our detection only kicks in for apps that do use one of those libraries.

> the Task Manager icon uses the icon from the app's .desktop file

Both native linux releases don't ship any .desktop files. Is the icon it displays thus some placeholder icon?
The AppImage does have a .desktop file internally, but not sure if plasma uses it in any way.

> This is caused by a quirk on X11

But if that's caused by X11, then why does it happen on Wayland as well?

> Our detection only kicks in for apps that do use one of those libraries.

That's likely to be the culprit then, as GMS1.4 uses OpenAL. Should I split this part into a separate feature request?

Also out of curiosity, why not allow the Icons Task manager to read the window's icon, like the tabview does?

For Wayland-native apps there is no such thing as a window icon

Running the appimage you linked I do get the correct taskbar icon though

Created attachment 152476 [details]
worksforme

> > Our detection only kicks in for apps that do use one of those libraries.

> That's likely to be the culprit then, as GMS1.4 uses OpenAL. Should I split this part into a separate feature request?

I don't know exactly how OpenAL is implemented on Linux, but what matters is whether the audio shows up as a stream in pulseaudio. If it doesn't there's nothing we can do about that

> worksforme

Well, how fun. Can local settings / distro somehow override the behaviour on how the task manager picks up 
icons?
Will try to check this out in a kde neon + arch environment the next couple days to see if it happens there as well, or only on my machine.

*** Bug 461328 has been marked as a duplicate of this bug. ***

*** Bug 491110 has been marked as a duplicate of this bug. ***

*** Bug 495474 has been marked as a duplicate of this bug. ***

> The panel displays a wrong icon, but the window switcher (alt+tab) displays the correct icon.

In my case it's the other way around: the Task Manager shows the application's icon (for most apps), while the window switcher shows a generic Wayland icon.

> the Task Manager icon uses the icon from the app's .desktop file, while the Task Switcher allows the window itself to define 
> a custom icon, and if it does, it displays it. If it doesn't, then it falls back to the .desktop file.

That doesn't explain my case so that's not the whole picture.

How many different standards or conventions are there for applications to define an icon? ALL of them should be supported (the only possible debate being about the priority order), in both the task manager and the window switcher, and everywhere else where an application icon is needed. So that if an application defines an icon in at least one way, it's picked up by the system. And whatever order of priority is decided, the same order should be applied everywhere.

Yeah, this is messy. And since the last few comments, now there *is* such a thing as a window icon on Wayland: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/269

Ultimately we need to determine if we want to have one source of truth for the icon or not. If we do, we have to deal with the messiness of window icons vs desktop file icons vs the placeholder icon, and them being able to differ (which can be a source of the issue here). If not, then this issue is basically a RESOLVED INTENTIONAL thing because there's no conceptually clean way to enforce that the icons match.

*** Bug 460403 has been marked as a duplicate of this bug. ***

*** Bug 498464 has been marked as a duplicate of this bug. ***

*** Bug 502070 has been marked as a duplicate of this bug. ***

To bring the point from another bug: https://bugs.kde.org/show_bug.cgi?id=460403

At least task switcher could have parity with task manager and use the same logic, since currently they don't.

In particular, Task Manager reads StartupWMClass value from the used .desktop launcher which allows setting it to what you need to make sure the icon shows up correct (works for example for games launched from Wine). But task switcher doesn't do it, showing generic Wayland icon.

That at least could be improved for Task Switcher too.

I looked into this a bit:

When window is started from a desktop file, it seems the window does not know about this desktop file. Instead, it gets the desktop file from the application the window is holding.

So for desktop file that starts kdialog, its the icon from kdialog. 

But plasma seems to know the desktop file that launched the application, so it picks the correct icon.

Yeah, they use different logic. Ideally they would both use the same library component to get the icon.

However, this would be complicated by xdg-toplevel-icon-v1 when combined with an Icons-Only Task Manager,, since the IOTM is designed to show the app icon, and explicitly *not* the window icon.

Idea:
- Icons-Only Task manager always shows the app icon
- Icons-and-Text Task Manager and Task Switcher both shows the xdg-toplevel-icon-v1 window icon (if present), badged with the app icon in the corner. If there is no xdg-toplevel-icon-v1 window icon, they both show the app icon.

Downgrading priority and severity, as this is just cosmetic and there's a window-rule-based workaround, annoying though it may for those affected.