Skip to content

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

Closed

Description

@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

Activity

  1. probonopd commented on Jan 31, 2023

    @probonopd
    Member

    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.

  2. Sodivad commented on Feb 1, 2023

    @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!

  3. probonopd commented on Feb 1, 2023

    @probonopd
    Member

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

  4. easyteacher commented on Feb 4, 2023

    @easyteacher
    Author
  5. probonopd commented on Feb 5, 2023

    @probonopd
    Member

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

  6. Pointedstick commented on Feb 5, 2023

    @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.

  7. easyteacher commented on Feb 5, 2023

    @easyteacher
    Author

    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.

  8. TheAssassin commented on Feb 5, 2023

    @TheAssassin
    Member

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

  9. probonopd commented on Feb 5, 2023

    @probonopd
    Member

    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?

  10. easyteacher commented on Feb 5, 2023

    @easyteacher
    Author

    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.

  11. probonopd commented on Feb 5, 2023

    @probonopd
    Member

    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?

  12. easyteacher commented on Feb 5, 2023

    @easyteacher
    Author

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

  13. locked and limited conversation to collaborators on Feb 5, 2023
  14. converted this issue into a discussion #1238 on Feb 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions