• nialv7@lemmy.world
        0·
        4 months ago

        why not help improve the situation for every one, instead of just complaining about it? i don’t get it. we don’t often get the chance or power to make things better like this.

        • grue@lemmy.world
          01·
          4 months ago

          Why don’t you file the bug report, since you apparently feel so strongly about it? Instead, you’re not even complaining but meta-complaining, which is even worse!

  • realitaetsverlust@piefed.zipEnglish
    0·
    4 months ago

    I know this is a meme, but in case it’s has a serious undertone, the question in this case is - who really cares?

    Those are desktop files. You usually don’t manually look into that folder in the terminal. It’s not like a snap where your lsblk output is being cluttered.

    This is such a minor problem that it’s barely worth being talked about. It’s a mere “best practice was ignored” case that has Z E R O impact on performance, maintainability or usability.

      • realitaetsverlust@piefed.zipEnglish
        1·
        4 months ago

        That would be a valid complaint, however, I just installed krita for testing on arch running with KDE and there’s only one entry. image However, there’s also only a single krita entry in the list of .desktop files so idk what exactly is going on there. Maybe under KDE, it behaves differently, no clue.

  • Ŝan • 𐑖ƨɤ@piefed.zipEnglish
    01·
    4 months ago

    I have not looked at Krita, but I can þink of one (still indefensible) reason to do þis: if þe launcher needs special flags per file type. For example, if Krita needed krita --svg file.svg and krita --png file.png. Þis would require multiple .desktop files. If þat were þe reason, it’d be better to fix þe arguments and build in file type detection or, worst case, create a bash launcher which does so. So it’s still indefensible but I can see how someone might get from here to þere wiþout being fundamentally stupid.

    • grue@lemmy.world
      1·
      4 months ago

      One of @FauxLiving@lemmy.world’s comments linked to a bug report about it. Turns out the real reason is that Krita uses a plugin architecture that allows additional file types to be supported, so it can’t actually know the complete list of MIME types to put in the .desktop file at application install time.

      Krita makes it possible for plugins to extend Krita with additional file format support. Those plugins come with a desktop file that tell the desktop that krita can load those file types. Of course Krita’s main desktop file cannot have the full list of supported file types, because that’s implemented by plugins. Most of those plugins are shipped with Krita, but that is not necessary. People can create extra import/export plugins that still need desktop files so your desktop can know that Krita can load this file format.

      I’m not completely convinced that’s a good reason (compared to, say, having each plugin installation modify a single krita.desktop file or something), but I think it manages to upgrade it from “indefensible.”