Create a symlink to the desktop file in local applications dir on startup

[easyteacher]

See https://nicolasfella.de/posts/fixing-wayland-taskbar-icons/ for more details

In short, on Wayland, a window manager can only match a window to a desktop file, and assign the icon from the desktop file to the window. So to properly show icons on Wayland, it's necessary to create a symlink to the desktop file in local applications dir on startup.

See also: https://invent.kde.org/plasma/kwin/-/merge_requests/3519

X11 Part: #779

[probonopd]

Thanks for looking into this @easyteacher, but this needs to be fixed properly in Wayland.

Wayland should not assume that people are using .desktop files. Wayland should be agnostic to such things, as X11 is.
Wayland should not require other projects to work around Wayland's XDG-centric assumptions when things work fine without such hacks in X11.

Wayland is a project that creates additional work for other projects by breaking things that were working fine for decades in X11, and I don't have the time nor energy to spend any time on it.

[Sodivad]

Wayland should not assume that people are using .desktop files. Wayland should be agnostic to such things, as X11 is.

Wayland doesn't care, xdg-toplevel interface adds the ability so applications can identify themselves to the system, you don't need a desktop file you can set it to whatever.

Wayland should be agnostic to such things, as X11 is.

Why? That's just your opinion. It makes sense to try to see if the app-id if one is provided matches a desktop file to get metadata about the application (like the icon).

Wayland should not require other projects to work around Wayland's XDG-centric assumptions w

Wayland is not "XDG-centric" in general, but having xdg-shell protocol rely on other XDG specs makes sense. They define how apps and desktops can interoperate together and xdg-shell is designed for desktop window managment.
Other platforms with different use cases would not use it but some other shell/none at all.

when things work fine without such hacks in X11.

For a certain degree of working. .desktop files are the standard way to identify and transport additional information about applications. Yes you could set an icon in some other way but by not providing the desktop file in a location where the Shell/WM could find it everything else that relies on it doesn't work either.

and I don't have the time nor energy to spend any time on it.

Luckily @easyteacher implemented it!

[probonopd]

Thanks for the clarification @Sodivad. I have never heard of xdg-toplevel nor xdg-shell, but then, all I ever use is X11.

[easyteacher]

Partially fixed in upstream

[probonopd]

So, is this caused by Wayland or by KDE Plasma?

[Pointedstick]

Ultimately the problem was caused by a mismatch between what AppImage provides and what Plasma (and other desktop environments) expected.

Plasma is now being nice by accommodating AppStream despite its non-compliance with XDG specs that desktop environmental typically expect compliance with, which I gather is intentional.

[easyteacher]

So, is this caused by Wayland or by KDE Plasma?

It's an issue with AppImage's deployment model, which can be kind of fixed by https://github.com/TheAssassin/AppImageLauncher . The fix in upstream is only a workaround for AppImages, to show icons in the task manager.

[TheAssassin]

@easyteacher if this is a bug in libappimage, please open an issue there.

[probonopd]

AppImageLauncher and libappimage are purely optional. The experience of how well a window manager can show icons should not depend on those optional components. So I would imagine that it would need to be fixed elsewhere?

[Sodivad]

As I said it's not only the window icons but everything else that relies on desktop files to identify applications will not work (also on X)

[easyteacher]

The experience of how well a window manager can show icons should not depend on those optional components

Because in wayland protocols there is no way to set an icon for a window, and there are some discussions in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/52 . But it's not only about the icon, The "Pin to task manager" feature also depends on desktop files.

[probonopd]

Imho the display server should be agnostic to how window managers work.

This is my main criticism of Wayland - no clear separation of concerns, and a "Linux Distribution" centric worldview. It all seems to be architected to mainly fit the Red Hat/Fedora/Gnome/XDG stack (and because people would otherwise complain, a bit of KDE, too).

What about using Wayland for non-Linux, non-XDG operating systems?

[easyteacher]

Wayland works on FreeBSD as well. I am not sure why XDG-centric is a bad thing.

[probonopd]

There are many systems that are not using XDG (e.g., GNUstep), or want to get away from XDG (e.g., helloSystem). There needs to be a clear architectural separation between the layers in the software stack, and each layer should not be biased toward/against certain choices in the other layers. The display manager should not be biased in favor of systems that use XDG. X11 shows how.