Is the resource manager forwards and backwards compatible?

Develop Developer Questions
1

In order to make it easier for users to add resource bundles to the Krita snap, I’m requesting the snap has access to ~/.local/share/krita/. This is not possible by default due to snap confinement.

While requesting the access, the following question came up:

Is krita’s resource manager forwards and backwards compatible such that on a system with krita from traditional packaging and krita as a snap are both installed, but with different versions, can the snap break the system’s krita or vice versa?

So is it safe to have multiple different versions of Krita use the same folder for resource bundles?

2

Not really; though you can manually set different locations for the resources with the XDG_DATA_DIRS environment variable by default every install of Krita writes resources and config to the same place.

1 Like
3

I’m assuming “not really” means “the resourcemanager is not really forwards and backwards compatible”? My question was phrased ambiguously so now I’m not 100% certain what “not really” means :wink:

I’m trying to solve the issue where users manually adds brushes to ~/.local/share/krita/brushes and expect Krita to use them.

The snap currently stores resources in ~/snap/krita/current/.local/share/krita. I could instead point the snap to ~/.local/share/krita/, but then all resources and config would be shared between the snap, the appimage etc. Since they might be a different version, I should only do this if everything is forwards and backwards compatible.

I can think of two ways to proceed if the resourcemanager is not compatible:

  • Either we try to teach users to only use the resourcemanager.
  • Or I copy the contents of ~/.local/share/krita/ to ~/snap/krita/current/.local/share/krita when the snap starts. But in this case, the resourcemanager still needs to be somewhat compatible.
4

Another question: does Krita use all possible locations for resources, or does it only use the single directory where it writes resources and config to?

i.e. Would it be possible to have Krita use ~/snap/krita/current/.local/share/krita for config and writing resources but also point it to ~/.local/share/krita/ using XDG_DATA_DIRS so it will also use the resources in that folder (but not write to that folder).

5

Can you maybe possibly explain what do you exactly mean by “forwards and backwards compatible”?

If you ask whether an older version of Krita will be able to read a resource folder written to by a newer Krita, then the answer is “mostly, yes”. If you ask whether a newer Krita will be able to read a resource folder written to by an older Krita, the answer is “mostly yes”. There are some limitations: for example in older versions of Krita there was a brush preset engine called “Dyna engine”; all presets using that engine can be only read by older versions of Krita. However the newer Krita doesn’t remove it or anything, just not use it. There are a few new features in brush engines that if the preset uses them, it will look differently in the newer version of Krita (that has those features) than in an older version of Krita (which still should be able to read it though). We do try to make sure that old resources are read the same way from version to version.

Note that there are people using multiple appimages on Linux or multiple portable versions on Windows already. Those are usually similar versions though. I do have Krita 3.3.3. appimage on my Linux (current version: 4.3.0) and it can read by Krita 5.0 (future version, not released yet, with resource system rewritten, more details later) read and written-to folder just fine.

Another note: we are in the middle of resource rewrite. There will be some differences in how the resource folder is used. Things that might not be compatible between versions before and after are (1) tags (they are imported, but all newly created tags will be, at least with the current design, only accessed in the new version), (2) information which presets are deleted by the user (since in Krita the user cannot delete anything, just hide it), (3) tasksets (technical reason; they are moved from one folder to another, so it’s possible to use older tasksets in Krita 5.0, but after one opening they won’t be accessible for older Kritas).

Also another note, from Krita’s interface users cannot really break much. Any resource that user “deletes” is just blacklisted, not actually deleted.

I don’t think it’s possible now to use several resources folder. In the new version it will be possible to define the resource folder in settings. In any case, Krita will need to have one “main” resource folder to keep its “what is deleted” information in (right now it could be possible to have it in several place, but the next version will have a database, and that’d be not good to have multiple of them).

I am going to implement Resource Manager that will hopefully solve the issues users have that make them fiddle with resource folder. I’m not sure how successful I’ll be at it, though. There are some users confused a lot with for example our nomeclature - “brushes” vs. “paintoppresets” especially.

1 Like
6

Thanks @tiar for your extensive answer!

The main question is “will anything seriously break when two different versions of Krita use the same resources folder?” From your answer, it seems like this would not be an issue with the current versions. Even better: this is already happening with AppImages and Flatpaks. Krita will just ignore resources it does not understand.

(3) seems the most severe case. since the tasksets will apparently disappear from older versions once you execute one new version. I think the advantage of having all Krita packages use the same folder for resources still outweigh this issue. Moreover, this issue will also be present in the Flatpak and AppImage versions of Krita.

So it seems to me that the best solution is to have the snap use the same resources folder as the AppImage and the Flatpak because then users can (manually) manage resources in the same place, regardless of what package they use.

Now I have one more question: what is the best way to make Krita use ~/.local/share/krita/ for resources when $HOME point to ~/snap/krita/current?

That sounds great!

7

Another question; given that you’re working on the resource-manager, you might be able to help. I noticed that in the snap package the “Open Resource Folder” button does not work. I don’t get any error message when I click it, however. Do you know how that button is implemented under the hood? Is there any way for me to get more debug messages from Krita?

Normally, a tool like xdg-open should “just work” inside of a snap so I’m not sure what is going wrong.

8

I’m sorry, I don’t understand this question. Can you elaborate?

And regarding issue (3), we might still change it - the core issue is that in the new version the folder for tasksets will be called tasksets and right now it’s called taskset. Right now in development version Krita checks for taskset and if it exists and tasksets doesn’t, it will rename the folder to the new name tasksets. User can just (1) rename it back, (2) duplicate the folder, (3) create a symlink… We could also create a symlink on Linux, too. (Simple duplicating would be a bad idea because then they might go out of sync). (Also: I don’t think there is lots of people out there using tasksets. They are a bit advanced feature. However I guess they must exists somewhere so of course we need to take it carefully, too).

Regarding issue (1), I want to somehow fix it too, we just don’t have a good idea how for now. In the development version of Krita tags are saved in the database, and since the older version doesn’t use database, it won’t know about new tags. We could however think about saving tags to the folder as well.

It seems to just trigger an action that does this:

void KisViewManager::openResourcesDirectory()
{
    QString dir = KoResourcePaths::locateLocal("data", "");
    QDesktopServices::openUrl(QUrl::fromLocalFile(dir));
}

and inside the locateLocal() it means QStandardPaths::AppDataLocation (+ /krita if it doesn’t have ‘krita’ at the end).

Btw it seems that the code could potentially support multiple resources folders… but that would be a pain to check and debug, I guess… and users generally wants us to ensure the resources can be in one place for all their Krita instances instead of the other way around (we get questions about resources on USB, or maybe in the cloud…).

9

You might have already answered my question but let me explain:

In snap packages, applications run in a container with limited access to the regular filesystem. The home directory inside of the container is not the same as the home directory outside of the container. Inside of the container, the home directory is /home/<user>/snap/krita/current/, while outside of the container it is /home/<user>/.

This means that by default, Krita in the snap will use /home/<user>/snap/krita/current/.local/share/krita as resources directory. Is there currently a way for me to tell Krita to use /home/<user>/.local/share/krita/ instead? An environment variable RESOURCE_DIR for example? (Krita has access to the “real” home directory, it’s just not labeled as “home”).

If there is no way to configure what path to use for resource directory, that is not an issue; I can also fix it using a symlink, but I wanted to ask first to make sure.

Thanks, it makes sense to only support a single resource folder. It is not necessary for the snap.

Thanks, I’ll take a look at why “openUrl” does not seem to work inside of the snap.

10

XDG_DATA_DIRS should work. I never tried it but it should. (You need to know the path to original $HOME though then :slight_smile: )

Also I’ve read your answer here: Auto-connect personal-files request for Krita - #12 by galgalesh - store-requests - snapcraft.io , could you please maybe add a link in your comment there to this thread? Just so the other can read it by themselves if they wish.