krita seems to only (or sometimes) use a built in file picker, which leads to inconsistent experiences between the system file manager vs within krita in some packages, and also a difference between behavior in the appimage/flatpack vs distro packages
a few thoughts:
a) krita is probably using some method of calling the system file chooser, but when it’s called on something like a flatpack or appimage where it’s not “directly” on the user’s system it ends up using some basic version available to it instead
b) I’m unsure how this impacts users on gnome, I might try to spin up a VM to check if it seems needed
c) it’s possible this isn’t usual behavior and I’ve actually stumbled onto a bug, but I don’t think that’s the case
CONCLUSION:
regardless of the cause, and assuming C is untrue, the official appimage and community flatpack have worse file choosers than native packages, and this should be fixed.
based on my current understanding, it seems like xdg-destop file chooser portal just needs to be implemented and that should fix it??
I’m totally willing to try to fix it myself, but I’m fairly inexperienced with real-world coding so if this is a difficult or somewhat complex task I’m probably not up to par, I also clearly need a better understanding of what’s really happening before I can try, hence making this discussion
disclaimer: sorry if this is a duplicate or if I’m speaking ignorantly here, I rooted around and couldn’t find any posts about this specifically. I also tried to surface research the topic best I could but I’m sure my understanding of desktop portals, flatpacks/appimages, and krita has plenty of blind spots
The first screenshot is the GTK/GNOME default portal file dialog.
Try installing the xdg-desktop-portal-kde if not already installed, and set to use KDE’s portal (I am not familiar with how to achieve this, should be easy to find).
This isn’t even specific to Krita’s flatpack, any flatpack would have the same symptom.
I should mention that xdg-desktop-portal-gtk is a very generic portal for non GNOME desktops. Since 2023, the xdg-desktop-portal-gnome overhauled the file picker to finally fix the thumbnail issue. OP has the option to use either the GNOME or KDE file picker. Recently, the portals has a configuration file. Lets say you decided on the KDE portal.
You would make a config file under (correct me if I’m wrong) $HOME/.config/xdg-desktop-portal/portals.conf and in it, put something such as:
I also tried gnome or gtk options in various combinations but nothing changed for krita or the other flatpacks I mention below (I also tried restarting because the docs are unclear when the config is called), which makes me think I’m doing it wrong or the necessary gtk/gnome stuff is not installed, but then how is the gtk file chooser getting called in the first place lol
I also tried adding org.freedesktop.impl.portal.FileChooser=kde to /usr/local/share/xdg-desktop-portal/kde-portals.conf but no dice
this would make sense, but my steam and prism launcher flatpacks don’t do this, and use the correct filepicker. so either this is incorrect or I’m just misunderstanding you
I wonder if they might be using a different flatpak “runtime” (collection of base libraries) than the Krita flatpak and the former are configured for portals while the latter tries something else.
The “native” (from system packages) version of Krita will very likely get its dialogs from the KDE integration plugin rather than the portal which is how you get the “correct one” for it.
Actually the dialog you get for AppImage and Flatpak Krita looks a lot like the standard Qt file picker. Which would be the fallback when they can’t load the host KDE integration plugin nor access the portal.
ok, after a recent update the file picker in the distro package is also the wrong one, seems to be the same one the flatpak/appimage uses. I left feedback on the update, but it’s unclear if it’s the fault of an update in the code by the devs or an update in the packaging by the maintainer
at some point I want to dig more into krita/appimages/flatpaks in general and figure out exactly what’s going on but I haven’t gotten around to it yet
thinking about it more, considering the appimage and flatpak were more up to date than the fedora package I believe, it’s possible this was just a code update that hadn’t gotten to the distro package yet. I should probably dig through the commit history
I tried changing DontUseNativeFileDialog in ~/.config/kritarc to both true or false (and restarting krita both times) but the file dialog stayed the same. then I tried deleting ~/.local/share/krita and ~/.config/kritarc {+kritadisplayarc} and it changed the dialog back to how it was before the update???
appimage (which pulls from the same locations by default if I understand right) still uses the same dialog as usual but we’re back to where we were before at least. really weird though, I have no idea why an update would make that not work while resetting my app state fixes it.
I also took a look at the commit history, there does seem to be a relatively recent commit related to this, and matches up with the fedora package updates to be changed in the recent update. so it looks like krita switched from QFileDialog to using KoFileDialog for it’s file dialog API. however now that I reset the state the native package still uses the same file dialog as before, so it doesn’t look like this commit caused the issue
something I noticed is the commiter exclusively says “K(o)FileDialog” in their notes and in the code but I was only able to find a KFileDialog (without the O) online. I don’t know if that’s important or not but just trying to dump any potentially helpful info for anyone interested
speaking of, sorry to flood the thread I just figured it’d be useful to have this information documented somewhere easily accessible instead of just in my head, lmk if I should cut it down or anything
also, I might be ready to file a proper bug report for this, but I’m not sure if I have enough info yet
anyway, I’ll keep digging
edit: now that it’s fixed, I realized I should change DontUseNativeFileDialog again from false (apparently the default) to true. this changed the file dialog to match the appimage and flatpak one! very interesting
It has no relation to KFileDialog. The reason for the Ko part of the name is historical I believe, from the times when Krita was part of KOffice.
Nowadays KDE applications use QFileDialog in C++ (QtQuick.Dialogs.FileDialog in QML), both of these should work to get the native file picker + work with portals.
If their wrapper has introduced some regression you should report to Krita on https://bugs.kde.org.
oh, thank you so much for the info! I’m so glad I mentioned that then. with all that in order I believe I’m ready to file a bug report, here is the link
