search

AppImage / AppImageKit

Package desktop applications as AppImages that run on common Linux-based operating systems, such as RHEL, CentOS, openSUSE, SLED, Ubuntu, Fedora, debian and derivatives. Join #AppImage on irc.libera.chat
http://appimage.org
Other
8.78k stars 563 forks source link

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

Closed easyteacher closed 1 year ago

easyteacher commented 1 year ago

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: https://github.com/AppImage/AppImageKit/issues/779

probonopd commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

easyteacher commented 1 year ago

Partially fixed in upstream

probonopd commented 1 year ago

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

Pointedstick commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

probonopd commented 1 year ago

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?

easyteacher commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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