I made a small tool for KDE Plasma (and other freedesktop desktops) that lets you easily customize single app icons:
- Use your own images or library
- Copy icon from another app
- Pick one icon from any installed theme (without switching global theme)
- Built-in pixel editor to create your own
- Batch apply, undo, overrides, missing icons overview
- Import image to turn it into an icon
Completely user-level, safe, and reversible. No manual .desktop editing.
GitHub: https://github.com/rayman1972/kappicon
AUR: kappicon or kappicon-git
Feedback welcome!-


Interesting approach to use a shell script with multiple in-line python calls inside shell functions. What is the intent behind this design vs doing it fully in python?
This design is inherited from the original macosicons-linux project by system-rw. The shell script + inline Python approach was already there for handling installation, XDG paths, desktop entry creation, icon cache refresh, and other system-level tasks. I kept the same structure when I forked and expanded it because it works well for a small utility ; shell for the “plumbing”, Python/PyQt6 for the actual GUI and logic. It’s pragmatic rather than pure. I might move more of it to a fully Python app in the future as the project grows, but for now it keeps things simple and close to the original setup.
Help me understand, how does it work well (or better than either pure bash or pure python)? From what I know, calling python multiple times in a shell script is very inefficient vs running a single full python script.
Also, for maintainability I try to avoid in-lining another language in a shell script as it is almost always more confusing code because of escapes. What am I missing that makes this way better?
The shell + inline Python bits are mostly because I forked from the original macosicons-linux project, which already used that pattern. The shell script is convenient for installation tasks (XDG paths, optional deps, desktop entry, cache updates, etc.) ; things that feel natural in bash for small Linux tools. For the CLI: the small Python calls are quick one off things, not performance heavy. The main GUI is pure Python/PyQt6 of course. You’re right though: spawning Python multiple times isn’t the most efficient, and inline code can be messy with escaping. It’s more pragmatic than beautiful. I kept it this way to get things working fast, which is not ideal long-term. If there’s a small user base and the program is actively being used, I’ll probably rewrite the whole thing.