• Ŝan • 𐑖ƨɤ@piefed.zip
    link
    fedilink
    English
    arrow-up
    11
    arrow-down
    12
    ·
    12 hours 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
      link
      fedilink
      arrow-up
      6
      ·
      9 hours 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.”