Sounds like a good idea; please test the new build.
Thanks @mino this install gave me the option of a new configuration directory.
For the windows installer additional pages for setting --configdir and setting a custom shortcut name have been merged into master.
Note: They are available for development builds only.
3 Likes
Well done…it will be handy to have…
1 Like
My concern about selecting a new configuration directory with the development build is what happens to the presets and styles I create between the two versions. Will they appear in both or just the version they were created in?
I’m not 100% if I understand your question. The new installer pages do exactly the same thing as manually editing the shortcut to specify a --config-dir. Just a bit more convenient and out of the box (and including writing the --configdir into the registry for the right-click-menu in the file Explorer).
If you install an additional dev build and choose a new config-dir that one will be empty and get populated with the new-install-defaults upon first startup.
If you want to carry over settings, presets and styles just clone the contents of the old config-dir into the new one, possibly without the library.db if you use separate image folders for the parallel installations.
1 Like
Thanks. While my question wasn’t clear your answer was what I wanted to know. Rightly or wrongly I let them share the same library.db and config-dir. Hopefully that won’t bite me on the bum on day.
@Terry I would strongly advice against that, a dev build may mess with your data greatly.
I am not talking about darktable’s nightly builds, those are generally safe. I am talking about experimental builds like mine, or @Christian-B’s, or @piratenpanda’s. Changes in these builds do not go through the same vetting process that PRs merged into master go through, they can do all kind of stuff to your data and make your edits no longer backwards compatible.
You do not need a separate config dir for each experimental build, one is enough. You can very well point all of them to the same library and config and if they mess up it’s not a big deal, since you are just playing with them.
So you can just make a copy of your configdir (including the library) and point all dev builds to that. You can always refresh the copy whenever you want, so that the dev instances are up to date w/ all the changes in your production one.
As a rule of thumb, data should never flow from your dev setup to your production one.
1 Like
sure, those need to be handled with extra care
I would also strongly advise against letting experimental versions share the config folder with your stable version.
What you can do before starting to use a new dev version, you can copy the content of the config folder of your stable version into the new config folder of the experimental version. This will transfer all your settings, css, styles presets etc. I’ve done that multiple times.
Edit: I just saw that @Masterpiga mention that as well
1 Like
Thanks for this @mino.
Over the last few years, I have been running separate installations using a customized shortcut to point to a different config folder. As I test several different builds, including experimental builds from forks, it’s nice not to have to customize the shortcuts each time now.
I’ve just installed a nightly build and I chose to use a different config folder, but I chose not to create a desktop shortcut. When I then went to \bin to create my own shortcut, the resulting shortcut obviously doesn’t display the config folder that will be used. It struck me that I don’t know how to check what config folder will be used. Is there a file in which this path is shown so I can just double check?
1 Like
The links created for the start menu launchers are just link files, too. I don’t know their location from the top of my head but in the launcher you can right click them and open the path they are saved in. Mak sense?
That worked, thanks! I hardly ever use the Windows Start menu anymore after installing Flow Launcher + Everything.
For anyone else interested, this is the process on Windows 10:
- Start menu > “darktable-dev”
- Click dropdown, right-click “darktable-dev” icon
- Select “More” > “Open file location”
- Right-click “darktable-dev” shortcut > “Properties”
- Target field should show the location of the config directory
The manual includes this bit:
" Tip: You can also copy an existing configuration directory into the new folder instead of starting from scratch. This allows the other installation to inherit your presets, styles, and keyboard shortcuts as a starting point, while both installations still run fully independently from then on. If you do this, take special care in step 3 to avoid affecting your existing edits."
The config folder contains database files as well as settings files, including backup database files from version upgrades. Copying the whole folder might be a bad idea. My production darktable config folder is currently at over 7GB!
Is it worth including a list of the files that only affect settings and interface so users can just copy those over?
Is it these ones?
I’d recommend including data.db as well as it contains the presets AFAIK.
The largest chunk is probably the library.db + snapshots in your case.
That wasn’t even my production config folder. My production one has 89 files, most of which are backup and SNP (snapshots?).
But there are some other folders and files too:
So, creating a master list of files to copy over might be hard. But maybe a list of files that are NOT needed to be copied over?
For now, I just want to know which files contain my GUI settings, presets and module layout.
1.) I suggest deleting all those older pre-x.x files as I suspet you will not go back to 3.4 at some point 
2.) darktablerc, shortcutsrc, data.db, styles folder, possibly lua folder and luarc and you should be good to go.
1 Like
Lol, you never know!
Yes, I know I have some housekeeping to do, but I’m a bit of a hoarder when it comes to backups.
2 Likes