I guess we can just add that to our list of places where we look. It feels a bit like a kludge, though.

Ah, that's what I thought. But all of this is dynamic in Krita, and depends on the the values of the XDG variables. If XDG_DATA_DIRS includes /run/host/usr then the profiles will be found, so we actually only need a way to set that before starting Krita. Does flatpak support that?

Actually, I'm not certain what the original reporter's problem is. When I go to

"Settings > Configure Krita > Color Management > Display > Add new color profile"

in a freshly installed Krita (no configs) running under flatpak, the file dialog opens in "/usr/share/color/icc" (host), as one would expect.

(The flatpak of Krita has the option --filesystem=host set, so it gets the same read/write access to the host, like a regular user.)

But if you opened another file (e.g. regular picture) before, the last location is remembered and maybe the problem is, that user might have trouble finding the location of the color profiles. So the solution might be to always open that path in there color management settings, instead of the last location.

There is a confusion, several actually. I do not understand why there are github and bugs.kde. I did not open this article, this confuses me...

The original problem was that Krita (Flatpak) does not have access to the ICC profiles `/usr/share/color/icc`. To calibrate my Hardware and my Software I need to have access to the profiles. This is understood, I suppose.

Krita has no problem. Flatpak has no problem.

The problem is "communicational". It took me a long time to learn that Flatpak accesses the profiles in this directory  `/run/host/usr/share/color/icc/`.

"I do not understand why there are github and bugs.kde.org"

The repository on github is a mirror. It exists because other people thought it would be a good idea for there to be a mirror on github of all KDE projects. I don't know why, it only causes confusion.

I do think it's a flatpak problem if system resources cannot be loaded; flatpak ought to be able to read from usr/share. Though, if colord is running, Krita will get your system profiles automatically (unless flatpak also makes it impossible to communicate with dbus to system demons -- I don't know about that.)

In any case, this clearly isn't a bug in Krita. If the XDG variables are set correctly, Krita will find its own default profiles, and there's much more that we can code.

> Though, if colord is running, Krita will get your system profiles automatically (unless flatpak also makes it impossible to communicate with dbus to system demons -- I don't know about that.)

How can I test this? Flatpak apps can talk to dbus, I just need to set the right permissions.

Depends on your desktop: on Gnome it's built-in, on Plasma you need to install the colord kcm. Then you can just select a display profile in the setttings application and Krita should see it automatically.

(In reply to Boudewijn Rempt from comment #7)
> Depends on your desktop: on Gnome it's built-in, on Plasma you need to
> install the colord kcm. Then you can just select a display profile in the
> setttings application and Krita should see it automatically.

To calibrate it is also necessary to select the CMYK profile.

(In reply to Boudewijn Rempt from comment #5)
> "I do not understand why there are github and bugs.kde.org"

Every time there is more confusion due to lack of information... Github is "only for errors related to flatpak". 


> In any case, this clearly isn't a bug in Krita. If the XDG variables are set
> correctly, Krita will find its own default profiles, and there's much more
> that we can code.

I already said it, it's not a mistake by Krita, nor is it a Flatpak error.

The error is that nobody reports that the access address to the ICC profiles has changed.

It seems that very few people who use FOSS have the need to calibrate the monitor.