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.

top 50 comments

sorted by: hot top controversial new old
[–] 99 points 5 months ago (1 child)

So thats fucking why?????????????????? omfg.

krita have so much in "open with" menu on gnome hily shit

  • source
  • hideshow 1 child comment
  • [–] 41 points 5 months ago (4 children)

    Anyone with any light to shed?

  • source
  • hideshow 4 child comments
  • [–] 72 points 5 months ago (2 children)

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

  • source
  • parent
  • hideshow 2 child comments
  • [–] 6 points 5 months ago

    Please never delete application's .desktop files unless you created them yourself. It can confuse both you and your package manager. If you want some file type to never be opened by a program, override it's .desktop file in ~/.local/share/applications instead.

  • source
  • parent
  • [–] 15 points 5 months 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.

  • source
  • parent
  • [–] 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.

  • 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.

  • 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.

  • 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

  • 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

  • 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.

  • source
  • parent
  • hideshow 1 child comment
  • load more comments (1 reply)
  • [–] 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.

  • 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?

  • 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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 13 points 5 months ago (1 child)

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

  • source
  • hideshow 1 child comment
  • [–] 11 points 5 months ago

    Damm, I learned a lot about Linux through this meme

  • source
  • [–] 9 points 5 months ago (5 children)

    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.

  • source
  • hideshow 5 child comments
  • [–] 7 points 5 months 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?

  • source
  • [–] 4 points 5 months ago

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

  • source
  • load more comments
    view more: next β€Ί