Skip to content

Use hicolor for icon install path #117

Description

@Dejweed

Please consider installing the icon into the hicolor/scalable/apps folder, as that's where other programs put their icons. That way they're all neatly organized.

Activity

  1. soreau commented on Apr 25, 2026

    @soreau
    Member

    I think the two main reasons we don't are to avoid potential name conflicts and plugins are not applications, so they don't really belong in hicolor/scalable/apps. Can you say how you intend to use the icons if not in wcm?

  2. Dejweed commented on Apr 26, 2026

    @Dejweed
    Author

    Upon taking a closer look, I now see that wcm.svg has two locations, /usr/share/wcm/icons/wcm.svg and /usr/share/icons/wcm.svg. I didn't realize this earlier. My issue is only related to the desktop icon /usr/share/icons/wcm.svg. Plugin icons are alright.

    I am testing XFCE Wayland session and I noticed the icon was missing in the xfce4-settings-manager. It does appear correctly in other apps and menus, so that is probably an XFCE issue.
    I'm also using KDE Icon Explorer and searching for wcm gives no results. So nothing critical, but moving /usr/share/icons/wcm.svg to /usr/share/icons/hicolor/scalable/apps/wcm.svg would fix these issues.

  3. soreau commented on Apr 26, 2026

    @soreau
    Member

    I am testing XFCE Wayland session and I noticed the icon was missing in the xfce4-settings-manager. It does appear correctly in other apps and menus, so that is probably an XFCE issue. I'm also using KDE Icon Explorer and searching for wcm gives no results. So nothing critical, but moving /usr/share/icons/wcm.svg to /usr/share/icons/hicolor/scalable/apps/wcm.svg would fix these issues.

    This sounds more reasonable.

    Upon taking a closer look, I now see that wcm.svg has two locations, /usr/share/wcm/icons/wcm.svg and /usr/share/icons/wcm.svg. I didn't realize this earlier. My issue is only related to the desktop icon /usr/share/icons/wcm.svg. Plugin icons are alright.

    I think the reasoning here is that one is so the menu can find it and the other is so the window-list widget can find it. I'm not saying that this is ultimately correct, but these are the cases for the icon that need to work. It might be better to attack this from the wf-shell side first, so that the menu and window-list widgets use the same algorithm to find the icon.

  4. added a commit that references this issue on Apr 26, 2026
    3a6cb5b
  5. soreau commented on Apr 26, 2026

    @soreau
    Member

    I wrote a patch to try this and it worked without needing to change wf-shell at all, so I made a PR for it.

    @Dejweed Thanks for pointing this out. Can you check if #118 writes to the expected location without adverse effects?

  6. Dejweed commented on Apr 26, 2026

    @Dejweed
    Author

    Looks good

  7. added a commit that references this issue on Apr 27, 2026
    84063a0
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