Problem
Hello! I'd like to share a suggestion based on my experience integrating the ClickUp desktop AppImage with soar.
ClickUp's AppImage internally identifies itself as desktop (its own filename and internal metadata use that generic name), so soar also names the icon file desktop-soar. Because the active icon theme (Breeze, on KDE Plasma) already ships a generic icon literally named desktop, the icon lookup for desktop-soar fails to resolve properly and the launcher ends up showing the wrong/generic icon instead of ClickUp's actual logo.
Reproduced with a clean remove + reinstall like this.
anifyuli@ThinkPad-L15G2a ~> soar list-installed
local.desktop-appimage/desktop@3.5:local (2026-09-05 04:16:17) (150.67 MiB)
╭──────────────────────────────╮
│ Summary │
├─────────────┬────────────────┤
│ ✓ Installed │ 1 (150.67 MiB) │
╰─────────────┴────────────────╯
anifyuli@ThinkPad-L15G2a ~> soar remove desktop
Removed desktop:local (3.5)
anifyuli@ThinkPad-L15G2a ~> soar add ~/AppImages/desktop-3.5.262x86_64.AppImage
✓ desktop: installed
✓ desktop:local [/home/anifyuli/.local/share/soar/packages/desktop-3.5-9a3f78b96ec4]
📂 Binaries:
→ /home/anifyuli/.local/share/soar/bin/desktop ← /home/anifyuli/.local/share/soar/packages/desktop-3.5-9a3f78b96ec4/desktop
╭──────────────────────╮
│ Installation Summary │
├───────────────┬──────┤
│ ✓ Installed │ 1/1 │
╰───────────────┴──────╯
The generated .desktop file:
[Desktop Entry]
Name=ClickUp
Exec=/home/anifyuli/.local/share/soar/bin/desktop %U
Terminal=false
Type=Application
Icon=desktop-soar
StartupWMClass=ClickUp
X-AppImage-Version=260717dcrpwg7m0
Comment=ClickUp Desktop
MimeType=x-scheme-handler/clickup;
Categories=Utility;
Note that Name=ClickUp is already present and correct in the very same file — but Icon= is instead derived from the AppImage's own internal filename/metadata (desktop) with a -soar suffix appended, rather than from the Name field soar itself just wrote one line above.
Suggestion: use the app's resolved Name (the same value written to Name= in the generated .desktop file) as the icon filename, instead of deriving it from the AppImage's raw internal filename or metadata. This avoids collisions with generic icon names already provided by the user's active icon theme.
Prior art: the exact same failure mode was reported for a different AppImage manager, aim, and fixed there by switching to this approach: slobbe/appimage-manager#1
This is just a suggestion — if it's not something you plan to implement, I still appreciate the work you've put into this project. Thanks for developing it!
Steps to reproduce
- Download ClickUp Desktop from official website
- Move it to ~/AppImages
- soar remove desktop
- soar add ~/AppImages/desktop-3.5.262x86_64.AppImage
Expected behavior
ClickUp Desktop icon can show properly
Soar version (soar -V)
0.13.3
Operating system (if issue is related to OS)
Fedora 44
Installation
Curl to official installer
Problem
Hello! I'd like to share a suggestion based on my experience integrating the ClickUp desktop AppImage with soar.
ClickUp's AppImage internally identifies itself as desktop (its own filename and internal metadata use that generic name), so soar also names the icon file desktop-soar. Because the active icon theme (Breeze, on KDE Plasma) already ships a generic icon literally named desktop, the icon lookup for desktop-soar fails to resolve properly and the launcher ends up showing the wrong/generic icon instead of ClickUp's actual logo.
Reproduced with a clean remove + reinstall like this.
The generated .desktop file:
Note that Name=ClickUp is already present and correct in the very same file — but Icon= is instead derived from the AppImage's own internal filename/metadata (desktop) with a -soar suffix appended, rather than from the Name field soar itself just wrote one line above.
Suggestion: use the app's resolved Name (the same value written to Name= in the generated .desktop file) as the icon filename, instead of deriving it from the AppImage's raw internal filename or metadata. This avoids collisions with generic icon names already provided by the user's active icon theme.
Prior art: the exact same failure mode was reported for a different AppImage manager, aim, and fixed there by switching to this approach: slobbe/appimage-manager#1
This is just a suggestion — if it's not something you plan to implement, I still appreciate the work you've put into this project. Thanks for developing it!
Steps to reproduce
Expected behavior
ClickUp Desktop icon can show properly
Soar version (soar -V)
0.13.3
Operating system (if issue is related to OS)
Fedora 44
Installation
Curl to official installer