So thats fucking why?????????????????? omfg.
krita have so much in "open with" menu on gnome hily shit
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
sudo in Windows.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.
So thats fucking why?????????????????? omfg.
krita have so much in "open with" menu on gnome hily shit
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.
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
If its that bad it sounds like it'd be an easy fix and you can upstream the change.
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.
Sure, but what's the point of this comment here?
This point is that Krita is pretty damned good.
I don't know, seemed like you were trying to diss GIMP
I'm not trying to diss GIMP. I'm dissing GIMP.
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?
No. I don't think the smart patch tool works nondestructively. There are three nondestructive systems in Krita:
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.
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.
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.
why are you posting here instead of sending a bug report to krita?
Asked and answered

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.
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.
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!
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?
You're the one who's upset about it.
You misread me, man. I wasn't upset, just suggesting what I believe is the right thing to do.
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.
You're encouraging mediocre work
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.
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.
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.
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).
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.
I like how you spell with þorn
That looks like porn to me
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.