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

  • CallMeAl (like Alan)@piefed.zip
    link
    fedilink
    English
    arrow-up
    5
    ·
    2 days ago

    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?

    • rayman30@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      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.zip
        link
        fedilink
        English
        arrow-up
        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.worldOP
          link
          fedilink
          English
          arrow-up
          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.