> Snap: Ver 5.2.11-Prealpha; this version has multiple bugs due to Snap deciding to use a now-very-outdated prealpha version of Krita
> Apt / Ubuntu: Ver 6.0.1; This is a beta version (helpfully shown to be such on the icon in Discover), and has issues because of it
> Appimage: All the versions are available; that said, for argument’s sake, 5.3.2.1; this version also has the inability to use native file picker, but also has the inability to… well, be installed, because it’s Appimage; this means that attempting to open the .kra via double-clicking does not work.
As stated in my prior thread on the issue, I very much would prefer to be able to use native file picker; I would also simply like to be on a version of Krita that’s not a beta version or, worse, outdated prealpha version. This means none of the four obvious methods of acquiring Krita are suitable.
Is there a fifth method of obtaining Krita? If so, how and where?
Krita refers to .kra files as “Krita documents”, they contain layer data, vector data for vector layers, ect; it’s the Krita equivalent of Photoshop’s .psd documents or Paint.NET’s .pdn documents.
With snap, apt, and flatpak, Krita is installed and thus integrated into the operating system; if you double-click on a .kra file, and Krita isn’t running yet, the system goes “Oh, this is a Krita file, I need to open Krita” and it opens Krita and hands it the file. It also, further, has the option to do the same for other image formats via right clicking and selecting “Open with >”.
With Appimage, it’s not integrated into the operating system, because it was never actually installed. Thus, it doesn’t show up in the “open with >” menu, and double clicking on .kra files opens up…
Well, on my system it opens the .kra file in Gwenview.
ah, so you need a .desktop file that launches your .Appimage
and then you need to assign that .desktop file to your .kra document extension so that it launches when you double click on the .kra file.
—
go to the launcher and right click for the menu to find “edit applications”
use this editor to create a new entry in whichever category you think best and where it asks you for what file to execute, point it at your .Appimage.
give his new entry a name you can find later and an icon you like and don’t forget to Save your work.
now go to settings > file associations and search for .kra
you should find it already associated with your native install (if you still have one), but you can now Add an application to the list which you should use to add your new .desktop file with the name you gave it.
move that sucker to the top of the list and it will be the default application that launches whenever you double click on a .kra file.
I mean… honestly, that brings Appimage to… being equal with Flatpak. Like, sure, it fixes the “I can’t open files from outside of Krita” issue, but it doesn’t fix the “Krita tries to use a non-Dolphin file picker and I don’t have a way of making it use Dolphin” issue that both Flatpak and Appimage share.
the native app is the one you want if you want it to use the native file picker, but if that version is the only version available from the default repositories, then you only have two choices left at this time:
add a compatible .deb repository with the version you want and hope it doesn’t put you in dependency hell.
compile the application yourself from source code and choose which version to compile, what dependencies it needs and which file picker it will use.
there may eventually be a backports repository available for 26.04 that could be populated with a better version (non-beta) … or you could file a bug report and see if it can be corrected in the main repository.
The removal of the now unsupported Qt 5 from many or most distro repos is the reason for the 6.x versions in places such as Ubuntu 26.04 and Fedora 44, and other recent distro releases. There won’t be a native Qt5 version of krita available from these.
Except this isn’t helpful (as in they’re not being helpful by choosing 6.x), because 6.x is still in beta. Like, if the icon literally has a beta symbol on it, I’d think that’d be a good sign that that’s not a stable release.
Depending which version of Qt and KDE Frameworks you build, the same source will result in one of the other. Both versions are almost functionally identical, with 6.0.0 having more Wayland functionality.
But note that since Krita 6 is still considered rather experimental, since it’s our first release based on Qt 6, and there were many complicated changes between 5 and 6.
But since Qt5 is no longer supported/deprecated/removed/whatever, the distros package the version that they are actually able to build. There is no choice other than to use the Qt6 option.
Most people are running the flatpak, or the appimage of the qt5 version, I will wager, and just living with the filepicker (eeew), and making filesystem access permissions adjustments as needed.
As a quick addition, without being on my computer right now, in general, flatpaks and appimages are my preferred way to install applications not immediately available in the os repository. To automate creation of a .desktop file (and sometimes also directly associating filetypes, otherwise Right Click - Other App - Always use this app), there are a few AppImage helpers, like AppImageLauncher and GearLever. I have used AppImageLauncher for a while until it had problems with Plasma, at which point I switched to GearLever, which is available on flathub. This should usually just intercept double clicking the file to show its window instead of the “execute file?” popup, otherwise again Right Click.
As for the other way around with the file picker, besides the builtin ones, apps usually have GTK and/or QT backends, QT being the plasma native one, as you have seen in your linked post. If I understand correctly, the bug affecting the file picker is currently affecting upstream/the current development versions, irrespective of distribution method. Otherwise you could go to the Krita Git (bottom right on the download page), and either build it yourself, or look for “artifacts” matching your requirements. These will usually be raw binaries, so no .desktop files or installation etc, and possibly mismatched dependencies. You might instead want to try setting the environment variables as the other linked bug report points out?
