You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Create a symlink to the desktop file in local applications dir on startup #1231
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.
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.
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.
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.
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.
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?
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.
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?
Activity
AppRun: create symlink to desktop file in local app directory
probonopd commentedon Jan 31, 2023
Thanks for looking into this @easyteacher, but this needs to be fixed properly in Wayland.
Wayland should not assume that people are using
.desktopfiles. 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 commentedon Feb 1, 2023
Wayland doesn't care,
xdg-toplevelinterface adds the ability so applications can identify themselves to the system, you don't need a desktop file you can set it to whatever.Why? That's just your opinion. It makes sense to try to see if the
app-idif one is provided matches a desktop file to get metadata about the application (like the icon).Wayland is not "XDG-centric" in general, but having
xdg-shellprotocol rely on other XDG specs makes sense. They define how apps and desktops can interoperate together andxdg-shellis designed for desktop window managment.Other platforms with different use cases would not use it but some other shell/none at all.
For a certain degree of working.
.desktopfiles 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.Luckily @easyteacher implemented it!
probonopd commentedon Feb 1, 2023
Thanks for the clarification @Sodivad. I have never heard of
xdg-toplevelnorxdg-shell, but then, all I ever use is X11.easyteacher commentedon Feb 4, 2023
Partially fixed in upstream
probonopd commentedon Feb 5, 2023
So, is this caused by Wayland or by KDE Plasma?
Pointedstick commentedon Feb 5, 2023
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 commentedon Feb 5, 2023
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 commentedon Feb 5, 2023
@easyteacher if this is a bug in libappimage, please open an issue there.
probonopd commentedon Feb 5, 2023
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 commentedon Feb 5, 2023
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 commentedon Feb 5, 2023
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 commentedon Feb 5, 2023
Wayland works on FreeBSD as well. I am not sure why XDG-centric is a bad thing.