471
Krita is doing its own thing (thelemmy.club)
submitted 5 months ago by to c/linuxmemes@lemmy.world
62 comments fedilink hide all child comments
 
Patrick, who has the Krita logo overlaid on him, and Man Ray have a back and forward pointing out that desktop files can have multiple file types associated with a programme by setting the mime type field. It ends with Man Ray insisting on Krita making one desktop file, but instead shows a list of desktop files with the format org.kde.krita.format.desktop.
you are viewing a single comment's thread
view the rest of the comments
[–] 16 points 5 months ago* (20 children)

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.

  • permalink
  • fedilink
  • source
  • hideshow 20 child comments
    •
  • [–] 35 points 5 months ago (7 children)

    My application menu did get cluttered with multiple krita entries.

    Which was a minor annoyance.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 10 points 5 months ago (6 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] [S] 19 points 5 months ago (5 children)

    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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 7 points 5 months ago (2 children)

    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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] 5 points 5 months ago* (last edited 5 months ago) (1 child)

    https://gitlab.gnome.org/GNOME/gtk/-/work_items/7776#note_2560841

    I honestly agree with the GTK devs here. The app chooser isn't what was meant by the spec and it should show all the apps available to the user. And if KDE respects NoDisplay in the app chooser, but still shows it if the MimeType matches, then I think that's an even more conjectural reading of the spec.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 5 months 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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 3 points 5 months ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 4 points 5 months ago* (2 children)

    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?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 9 points 5 months ago* (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 5 months ago (8 children)

    You're encouraging mediocre work

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] -1 points 5 months ago (7 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 6 points 5 months ago* (4 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 5 months ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 5 months ago*

    This is true, but it is not possible to solve every problem you come across; sometimes the most you have time to do to help is to provide feedback. It is also much more efficient for someone who already has experience and familiarity with the codebase to make the change. "Do it yourself" should not be the first option taken.

    For example, after learning from experienced people in this thread, I now know that if I had tried to implement this change myself, it would either be rejected or I would have wasted an hour or two of research finding out why it would be rejected-- apparently this program's plugin system has plugins make new desktop files, so it's done this way for plugin support. An experienced maintainer of this project would know that and avoid wasting time on a change (or have the social authority to make the choice to move to a different desktop file system for plugins).

  • permalink
  • fedilink
  • source
  • parent