So thats fucking why?????????????????? omfg.
krita have so much in "open with" menu on gnome hily shit
this post was submitted on 14 May 2026
453 points (98.5% liked)
linuxmemes
31449 readers
1320 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack users for any reason. This includes using blanket terms, like "every user of thing".
- Don't get baited into back-and-forth insults. We are not animals.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn, no politics, no trolling or ragebaiting.
- Don't come looking for advice, this is not the right community.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, <loves/tolerates/hates> systemd, and wants to interject for a moment. You can stop now.
5. 🇬🇧 Language/язык/Sprache
- This is primarily an English-speaking community. 🇬🇧🇦🇺🇺🇸
- Comments written in other languages are allowed.
- The substance of a post should be comprehensible for people who only speak English.
- Titles and post bodies written in other languages will be allowed, but only as long as the above rule is observed.
6. (NEW!) Regarding public figures
We all have our opinions, and certain public figures can be divisive. Keep in mind that this is a community for memes and light-hearted fun, not for airing grievances or leveling accusations. - Keep discussions polite and free of disparagement.
- We are never in possession of all of the facts. Defamatory comments will not be tolerated.
- Discussions that get too heated will be locked and offending comments removed.
Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.
founded 2 years ago
MODERATORS
I just hate it, need to remove Krita, stopped using it after Gimp is Wayland native.
Anyone with any light to shed?
.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.
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.
Googling the issue i found this
https://bugs.kde.org/show_bug.cgi?id=403194
Says its because gnome isn't supporting that freedesktop standard for some reason. This is a non issue in kde
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.
If its that bad it sounds like it'd be an easy fix and you can upstream the change.
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.
My application menu did get cluttered with multiple krita entries.
Which was a minor annoyance.
That would be a valid complaint, however, I just installed krita for testing on arch running with KDE and there's only one entry.
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.
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):
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
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.
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.
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.
This isn't a directory, it's the list of apps that show up when you right click a file and select 'Open With'.
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?
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.
I guess it depends of a bunch of things, but why when programmers package a program don't do the same more often?
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...
Gnome shows like a million of open with Krita entries.
Damm, I learned a lot about Linux through this meme
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?
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.
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.
load more comments
(4 replies)
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.
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."
I like how you spell with þorn
That looks like porn to me
view more: next ›