Just recently discovered that Darktable (DT) now offers a version that runs on Windows. Therefore, decided to give it a try. In my case, it is preferred to run such software in a portable fashion. At present I’m pretty low on the learning curve but did notice that DT stores some files in user specific folders. A convention used on Windows is to identify these locations using environment variables. For example, there is an environment variable named LOCALAPPDATA which by default Windows sets to “C:\Users\uid\AppData\Local” (where uid is the username of the user executing the program). This appears to be the location where DT has chosen to create a folder named “Darktable” that is used for the purpose of storing such user specific data.
However, it also appears that DT does NOT use the environment variable for finding this folder. This creates a significant problem for those of us who prefer the software to be isolated on a drive of our choosing which can be moved from one computer to another. In that, the software/program along with the user specific data is NOT bound to a specific computer. The only thing DT needs to do to facilitate this user preference is to use the mentioned environment variable for the purpose of locating such files. Then the user can write simple scripts to set the same environment variables to their preferred location and everything works the same as it presently does.
I run just about all of the software on my Windows systems in this fashion. Also, there is a very popular program called Portable Apps. While it is Windows specific there is a multitude of applications that are supported by this platform which is specifically designed for this purpose. Darktable would likely increase its’ popularity amongst Windows users considerably by adapting to this platform which may NOT be much more difficult than making the kind of change mentioned above.
It is important to notice that this change would have NO affect on users who prefer the current method of operation. My guess is that it would also align better with the technique used for locating these files on other platforms such as Linux and OSX.
Another factor that can aid portability on Windows computers is to avoid the use of the Windows registry. This is quite a common practice for software developed for use on other platforms as well as Windows and as best I can tell DT operates in that fashion.
We are really short on windows specific devs, so if you can contribute or know of someone who can, that would be great. Otherwise I would not expect to see too many platform specific things for windows.
You can use my strategy, so just install it anywhere you like and add a small batch file to run it from whatever you launch it…also add a config directory locally to that folder and if you need all things contained you would finally need to put your thumbnail image cache there…This might not be practical for a “portable” install… but you can direct the location of the kernel and thumbnail cache files… if you need them otherwise they will be created in the Windows user data as well… You can now also create a zip file of this install that you can install it as a “portable” version on any computer. As for the environment variable… if you run DT using the --configdir parameter you can use any directory you want for the config files… That is what I do for a portable version ie use that parameter in the aforementioned batch file and add a local config directory…
Looks like that solves the problem that provoked this post. I’d even say that is even a better solution insofar as it is a little more customizable. I’d also acknowledge that Darktable (DT) is NOT unique with respect to my initial complaint. Disregarding the Windows environment variable is very common practice.
I also notice that the DT initiation parameters include something called “–datadir” in addition to “–configdir”. At present it looks to me like the default location for what is referenced by “–datadir” is “–configdir”. Maybe --datadir allows the so-called databases to be located separately from --configdir if desired. Yeh?/Neh?
However, now that I have --configdir working it exposes something else that looks like it might be an even more serious problem. I’m still very low on the learning curve for using DT so this might have as much to do with my ignorance as anything else. DT has something it calls a database (referenced above) that has something to do with identifying, to include locating the files, to be processed. In that, it seems to need/want to know more than what the file system has to offer. However, this includes reference to the file system. As a result, when you start DT on a different computer (i.e., even one that uses the same keyboard and display) those files go missing. Possibly even when they are on the same, portable, drive but with a different drive letter assigned. This has never been a problem with other software that I’ve used for image post-processing. Those programs seem to get by just fine by relying only on the file system (and of course sidecar files). From what I can see so far this has the affect of binding DT somewhat strongly to use on a given computer. While I’d still prefer being able to install in portable fashion for other reasons this is a significant negative characteristic of DT. What am I failing to understand?
That if you make a batch script and define the variables you mention above and a few others, you can make dt store its data wherever you want. This is all detailed in the docs: darktable 3.8 user manual - darktable
@priort has a bat script which does this that he can probably share.
This document explains fairly well the organization of DT… As for files you have to make some decisions…if you need the database and its functions you need to mind the file locations if you change locations…you can use a symbolic link to sort of “trick” DT but you can also use DT with another option called :memory: this creates a temporary library each time you run DT in memory. In this way you can use it as simple editor and rely on the sidecar files for your editing information…
The ability to specify separately the database and the library give you the ability to keep separate versions say one for your personal and one for your work or whatever arrangement is needed. Then you invoke the same installation of DT but with the specific parameters to direct it to use the database and or library you want… I rarely use the library. I use memory and just use DT as an image editor…
I did spend some time reading about what DT calls Collections. That looks to be way past my level of sophistication but I can see how it would be useful in some scenarios for more advanced photographers. Particularly when dealing with larger numbers of files.
The “:memory:” feature, you describe, does sound like it might be helpful for me. I’ll spend some time to learn more about it and probably give it a try. Thanks for pointing that out.