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

  • rayman30@lemmy.worldOPEnglish
    7·
    2 days ago

    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.

    • CallMeAl (like Alan)@piefed.zipEnglish
      2·
      2 days ago

      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?

      • rayman30@lemmy.worldOPEnglish
        1·
        2 days ago

        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.