I use Krita on a desktop machine that dual boots Manjaro Linux and Windows 10. Usually I use the Linux side for Krita and app development, and Windows for gaming, but a recent bug in Gnome has made my drawing tablet stop working in Linux. I downloaded Krita on Windows, and found that the tablet works fine over there. Now comes the task of migrating all my brushes, keyboard shortcuts, new canvas templates, etc from one OS to the other.
I have done this sort of thing more than once before, but not often enough to avoid needing to look it up each time. There is helpful documentation on the subject, as well as a couple of topics on this forum (#49795 and #66642), but Iām still left guessing which files I actually need, where they belong on each OS, and so on. I run into this issue every time I reinstall my OS, or try to use Krita when Iām out of town on my laptop.
It would be really convenient to have a tool in the UI to do this for me. I notice in the menu bar, under Settings, there is a Reset All Settings option. Why not add Import/Export All Settings here as well? This way, all these customizations can be packed into a single file, moved to the new machine or OS, and be left with no ambiguity as to what this file is or where it needs to plug in.
I have already discussed part of the problem of creating such a solution in the topic linked by @AhabGreybeard.
In order to integrate something like this into Krita, Krita would need to know which platform is being moved to and, depending on the operating system, it would also need to know which type of installation is involved in order to copy the files and directories to be transferred to the correct locations.
In some cases, depending on the system, administrator/root rights would have to be assigned in various ways in order to complete this. Also, the new username on the target system must be known, all this in order to be able to patch the kritarc correctly with the data obtained in this way, and to move/copy everything to the right places.
But at the latest when it comes to Linux, the task becomes an impossible task, unless you leave out the repository installations of Krita, but then I can already hear the cries of āWhy did you leave out distributions/my distribution?ā.
In addition, there are probably users who have little or no knowledge of computer technology and will not know what to enter into the input mask required for such a move in the questions about target system, type of installation and username, although this could be partially solved by selection menus.
Even if Krita had a large development team it would be almost impossible not to maintain this permanently, with the handful of developers available to Krita it is probably not even initially feasible to develop it, let alone maintain it permanently.
Most of the work should happen in the target Krita. The target Krita knows where its own installation files are stored and itās already abstracted in the code so that a coder never has to think about that. The source Krita shouldnāt have to do much more than just pack up all its settings. So thatās not the problem I see. The work would be to determine which parts need to be omitted when copying over (things like ffmpeg install path, cache dirs, krita window size if that gets stored) and which are paths that need changing. Though some of the former might already fix themselves, like recently opened files already checking whether the path is still pointing to a valid file, and the latter might be done somewhat smartly. What you want to avoid at all if possible is having specific rules for individual settings, because thatās going to break when new settings get introduced.
If all the settings are exposed to the Python API, it might be a suitable task for a Python Plugin. Itās good at that kind of data shoveling/processing.
If one can do this in a running Krita, then that could work. So importing the whole resource folder, switching the database, and adjusting the paths in the kritarc.
It should be possible to do with a plugin, something like this (this is just an example of how one would pull the data and paths for zipping):
from krita import *
import os
# path of config files
conf_path = QStandardPaths.writableLocation(QStandardPaths.GenericConfigLocation)
kritarc = os.path.join(conf_path,'kritarc')
kritadisplayrc = os.path.join(conf_path,'kritadisplayrc')
kritashortcutsrc = os.path.join(conf_path,'kritashortcutsrc')
print ( "PATH TO KRITARC=", kritarc )
# load up kritarc settings
kritarc_settings = QSettings(kritarc, QSettings.IniFormat)
print ( "RESOURCE DIR=", kritarc_settings.value('ResourceDirectory') )
# get list of settings, should be copied, changed with variables and synced to a copy then zipped.
# also consider what to do wether to copy ten scripts files or not
for key in kritarc_settings.allKeys():
val = kritarc_settings.value(key)
if val and val[0].startswith('/'):
print ("PATH=", key, val)
You would then replace the variables with the parameters on import
That would be a cool thing if, in a running Krita, even the locked āāresourcecache.sqliteāā could be exchanged with the one to import. The resources that are loaded into Krita during the import must be dropped in some way to make place and to not collide with those to import. Sounds very good, would spare masses of work here in the support category of the forum.
The thing of a running Krita was all I was thinking about, as a non coding person. If that is really feasible, it would probably make many users very happy.
It would be fundamentally no different than when you go into configure Krita and change the path to the resource folder. After you import you are going to have to restart
Yep, not thought about that, probably because I never have changed the location of my resources.
Michelist
Add/Edit: Then all that is needed now is the implementation of this feature. From the helperās point of view, I therefore support this feature with my vote in favor.
@JusticeWatch: You should vote for your feature request, as I did, to show your support for your own request. In this way, we show the developers our interest in a desired feature. The more votes, the greater the chance of implementation. But there is no guarantee of implementation, as the developers are free to decide what to implement. Things that violate Kritaās roadmap or the ethics behind Krita will therefore not make it into Krita this way, no matter how many votes they generate.