• Fizz@lemmy.nz
    3·
    22 hours ago

    If its that bad it sounds like it’d be an easy fix and you can upstream the change.

    • fonix232@fedia.io
      71·
      2 days ago

      .desktop files are essentially used similar to Windows’ registry - you create such a metadata file in a specific location, and it acts as a launcher, autostart setup, and file type assignment (so you can easily assign e.g. PNG files to open with Krita by default).

      As the wiki says, you can put multiple MIME types (file type descriptor such as “text/plain” or “application/json” or “image/jpeg” and so on) onto one dotdesktop file, meaning you only need a single launcher to support all file types.

      Krita explicitly creates quite a few dotdesktop files, each supporting only a single MIME type.

      Downside: littered desktop.

      Upside: you can easily pick and choose which file types to open with Krita directly.

      Most desktop environments actually handle the [samename]. extension.desktop repetition so you’ll only have one Krita launcher entry but it will still collate all MIME type support that is present. Want to exclude e.g. BMP files? Delete the .bmp.desktop file.

    • rtxn@lemmy.worldM
      15·
      2 days ago

      XDG Desktop files are a mostly standardized way to integrate individual programs into the desktop. For example, a desktop file in /usr/share/applications or ~/.local/share/applications can add programs to the application launcher, both desktop launcher menus and separate apps like dmenu-run; or they can be used to start applications when the desktop session starts by placing them in ~/.config/autostart.

      Desktop files can also set properties related to an application. In this particular case, the MimeType field tells the desktop session what MIME types should be associated with the application. For example, my desktop file for Blender associates the application/x-blender MIME type with it, which causes Blender to show up in the Open with… dialog.

      The MimeType field is a semicolon-separated list. One desktop file can define multiple associated MIME types for the same application. Krita instead creates a separate file for each association.

  • realitaetsverlust@piefed.zipEnglish
    193·
    2 days 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
        9·
        2 days 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.

        • flamingos-cant (hopepunk arc)@feddit.ukOPEnglish
          19·
          2 days ago

          It won’t show up there because the files have NoDisplay set to true, which hides them from the desktop app view, but they still show up in other places. Here’s Nautilus’ open with dialogue (where I noticed this):

          Short video showing a scrolling list of apps showing many entries for Krita

          • mexicancartel@lemmy.dbzer0.comEnglish
            6·
            18 hours ago

            https://bugs.kde.org/show_bug.cgi?id=403194

            They says it’s freedesktop standard, and gnome is at fault for not implementing the standard properly. I don’t have this issue in KDE. I don’t understand what it meant different files are supported by different plugins, but maybe internals depend on that structure.

            Anyway gnome should be supporting that standard everywhere in all their apps

              • mexicancartel@lemmy.dbzer0.comEnglish
                1·
                14 hours ago

                I would like to see what are differences in content for thoose different desktop files. Is there any difference in launch options? Do they contain mimetype feilds? It seems like specification explicitly states it(Nodisplay) being useful for mime types so it probably is expected feature within the spec. Also spec says nodisplay should hide from “menus” which i’m not sure if its just app launcher or all menus

                The argument I see all over here (from kde side) is that support for mimetypes are optional plugins, and within the spec making multiple desktop entries is the only choice when doing so.

          • realitaetsverlust@piefed.zipEnglish
            41·
            2 days ago

            Okay but that would mean you have to open /etc/share/applications in a file explorer which you - usually - don’t really do. Or maybe I’m just too much of a terminal guy to do it.

    • liinux@pawb.social
      4·
      2 days ago

      I’m not sure about this case because I don’t use flatpak that much, but to be honest I hate when I install an Electron based program such Freetube, and even though I installed the BIN binary (arch btw, not happened this on Debian based distros) for some reason my package manager decided to install the whole Electron framework with DE included. I get that it depends on it to work, but I don’t need 40 Electron packages to show in my Wofi that I would never use, is so ugly. The same with Qt programs and any single KDE app (but I understand in this case)

      I mean, yeah I understand that Freetube depend on Electron to work, but why when installing Steam this is not the case?

      • realitaetsverlust@piefed.zipEnglish
        9·
        2 days ago

        but why when installing Steam this is not the case?

        Because steam has no application-dependencies, it bundles everything into one binary, including the electron binary, and ships everything in one go. However, steam still has system-dependencies that have to be installed and will pop up in rofi.

        • liinux@pawb.social
          1·
          2 days ago

          I guess it depends of a bunch of things, but why when programmers package a program don’t do the same more often?

      • realitaetsverlust@piefed.zipEnglish
        34·
        2 days ago

        I don’t know if you’re ragebaiting or are just a massive fucking asshole tbh, but when someone develops an application for free and for fun for anyone to use, I’m not complaining about too many fucking .desktop files.

        • Feathercrown@lemmy.worldEnglish
          6·
          2 days ago

          Apparently it causes issues with “Open With” menu entry spam in some DEs. It’s a minor issue but easily solvable and it impacts usability.

          • realitaetsverlust@piefed.zipEnglish
            4·
            2 days ago

            If that’s the case, that would be a fair complaint that should be fixed, but I can’t really reproduce any problems on KDE or XFCE. Then, it should also be reported as a bug so they’re aware.

          • prenatal_confusion@feddit.org
            1·
            2 days ago

            While I agree that the seva should have looked out for it in the first place I think it being volunteer work and open source you or anybody else that has the time and knowledge could fix it too and give back. If it’s indeed easily solvable.

        • wrinkle2409@lemmy.cafeEnglish
          31·
          2 days ago

          It doesn’t mean it is free that it has to be mediocre. I also do work for “free and fun” and I don’t see it as a reason to take a shit on my project. Either accept criticism or just keep the damn code for yourself.

  • Ephera@lemmy.mlEnglish
    13·
    2 days ago

    Hmm, what distro? I don’t use Krita regularly, but never seen it have lots of desktop files.

    I do be on KDE, though, so might also be some KDE-specific fix, I guess…

  • sepi@piefed.socialEnglish
    7·
    2 days ago

    Ok. You have a valid point. But hear me out here: what if we just use a bajillion desktop files instead? How many do you think this unholy contraption can hold?

  • it_depends_man@lemmy.worldBanned from community
    123·
    2 days ago

    This part of the UX and development of linux is still very much taking baby steps unfortunately. Massive lack of interest and manpower to do these things cleanly and provide good documentation.

    • scrion@lemmy.world
      381·
      2 days ago

      This is nonsense. The documentation is readily available, and it takes arguably less time to provide the code to write a single, proper file than to create 50 desktop entries.

      This is just ignorance on whoever wrote that part of Krita.

        • vagrancyand@sh.itjust.worksEnglish
          15·
          2 days ago

          Because distros don’t do it differently. Different DEs sometimes deviate from the established standards and practices. It’s not a distro change, it’s whatever weird little DE you use that decided to do something stupid.

          That being said .desktop is a unified standard with unified documentation implemented in a fairly unified way across various DEs, with the only difference is some DEs support finding desktop files in some extra folder locations.

          Every distro could maintain a complete list of popular DEs and a link to the documentation, or people could just look it up for the DEs they use and target. I agree there should, at this point in time, be some standard service to just call and handle desktop files that all DEs use that way application level developers can just call that same service and everything gets put everywhere it needs to be, but given the controversy of systemd, there’s not going to be a universal solution for that since this is absolutely not a kernel-level service that needs to happen.

  • Ŝan • 𐑖ƨɤ@piefed.zipEnglish
    1411·
    2 days 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
      9·
      2 days 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.”

  • Paranoid Factoid@lemmy.world
    88·
    2 days ago

    Krita has a fully nondestructive workflow, including alpha masks for filters. It’s had it for fifteen years or so. GIMP is still trying to catch up.

    • Hinori@scribe.disroot.orgEnglish
      1·
      17 hours ago

      I’m not entirely sure, but I feel like you know something about nondestructive editing in Krita! Can I ask you some questions about it?

      Is it possible to use the smart patch tool in a nondestructive manner? I’d like it to take samples from the underlying layer(s), but apply the result to the upper (empty) layer. Just like the clone brush can do. Is it possible to do it in this way?

      • Paranoid Factoid@lemmy.world
        1·
        10 hours ago

        No. I don’t think the smart patch tool works nondestructively. There are three nondestructive systems in Krita:

        1. Alpha Masks. This lets you edit transparency for a given layer. A common use is to remove backgrounds. But you can also paint or use the gradient tool for soft transitions. Gimp has had this too since at least the 2.10 series. Perhaps 2.8.

        2. Alpha masking of adjustments. This lets you paint or use the gradient on an adjustment layer, such as Curves or Levels. Again, to allow for soft transitions of adjustments. Note that GIMP 3.2 currently CANNOT do this. It does have adjustments, which are called ‘filters’ in GIMP speak. And like Krita, they can be reordered in an adjustment/filter stack. But unlike Krita (and Ps), an adjustment/filter currently only applies to an entire layer. The adjustment can not be edited within the layer itself on a mask.

        3. Layer Styles. This is commonly used for nondestructively adding styles to text, like drop shadow, sparkle, glow, etc. Gimp got this in 3.0.

        Gimp has made some real improvements with the 3.x series. But it still lacks basic functionality that Ps has had since 1997 with Photoshop 7.0, and Krita has had for something like fifteen years. But it’s getting there. And it does have better adjustments/filters than Krita. And it has had editing text on the canvas since 2.10 (I think?), whereas that’s being deployed for Krita 6.0 I believe.

      • nialv7@lemmy.world
        31·
        2 days 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.

        • FauxLiving@lemmy.world
          91·
          2 days ago

          Sir, this is a c/linuxmemes

          I’m sure the OP is capable of doing multiple things at once.

          Also, Krita is aware of the issue and is doing this intentionally. They set the NoDisplay=true option in the .desktop file so that users of DEs that are built to the freedesktop standards will not see this ‘issue’.

          The only people affected are the ones who are manually digging around their .desktop files, in which case they should be more than capable of understanding why these files exist and why it doesn’t matter that there are multiple.

        • grue@lemmy.world
          32·
          2 days 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!

          • nialv7@lemmy.world
            3·
            2 days ago

            i don’t even use krita? what am i? the bug concierge, just collecting people’s complaints around the whole internet and file bugs for them?

              • nialv7@lemmy.world
                3·
                2 days ago

                You misread me, man. I wasn’t upset, just suggesting what I believe is the right thing to do.

                • grue@lemmy.world
                  12·
                  2 days ago

                  Well, you sure sound upset, and you’re downvoting both me and the other guy who replied to you, so…