darktable
darktable copied to clipboard
darktable-org
Allow to change default path for created xmp files
Is your feature request related to a problem? Please describe. I'm frustrated when I use "preview" app of MacOS and navigate through photos with up/down arrow keys and every other file I got preview of .xmp file like in the video
Describe the solution you'd like it would be nice if darktable would allow to set a path to xmps pattern up - like /${photosFolder}/${xmp_data} - or whatever that wouldn't put xmps in the same folder as the original photos
Alternatives N/A
Additional context
https://github.com/darktable-org/darktable/assets/4653046/3767eb65-fc5f-400f-84cd-e05e50cab27f
Why not just sort by kind in Finder?
I do as a workaround, but then other sorting is lost - for example when i have multiple day sessions with everyday review, i like to sort by “date created”
What you're describing is a problem with the behavior of that "preview" application - not darktable. Storing XMP sidecar files alongside the image in the same folder is industry-standard behavior.
You can disable XMP files entirely in darktable and instead rely on the darktable database to store image metadata if you so choose. Otherwise consider changes to your workflow (like @darkelectron suggested with filters).
An argument that led to nowhere was held in another issue, but I think an important point was brought up, in that new users may find the behaviour of DT and the creation of sidecar files confusing.
I think a simple solution could be to add to the 'never' option's tooltip for creation of sidecar files (PO for the english string here) to explain that changes will still be stored in DT's database, but, by not keeping XMP files on, if the user moves a file to a different directory outside of DT (or causes the file to no longer be found through the db by some other mechanism, the db has no easy way of recovering those changes.
I've only been using DT for a few weeks, and I was also first puzzled and a bit frustrated when all my raw files suddenly had a weird .xmp file next to it. After reading the docs, I found the setting and am happier to have the option to only create a sidecar file upon edit. But I'm a developer by trade, not a typical user. Someone (a typical user) looking to, for example, ditch the Adobe ecosystem for a FOSS alternative (for ethical or other reasons) might pass on DT because of the frustration/confusion of the XMP files being created in their working dirs with no explanation.
BUT, I also think that it's a lot of effort to build out the feature to store XMPs in a separate directory that won't cause additional frustration, due to user error (see remarks on moving files to different directories above).
So, TL;DR: I think it'd be helpful to display am explainer for the 'never' option in the XMP creation option's tooltip.
I'm happy to work on the English string and solicit translations (once I find my way around the codebase a bit more) and make a PR for this.
An argument that led to nowhere was held in another issue, but I think an important point was brought up, in that new users may find the behaviour of DT and the creation of sidecar files confusing.
I think a simple solution could be to add to the 'never' option's tooltip for creation of sidecar files (PO for the english string here) to explain that changes will still be stored in DT's database, but, by not keeping XMP files on, if the user moves a file to a different directory outside of DT (or causes the file to no longer be found through the db by some other mechanism, the db has no easy way of recovering those changes.
re-importing the file will attach it's edits from the library.db provided the file name is the same
I've only been using DT for a few weeks, and I was also first puzzled and a bit frustrated when all my raw files suddenly had a weird .xmp file next to it. After reading the docs, I found the setting and am happier to have the option to only create a sidecar file upon edit. But I'm a developer by trade, not a typical user. Someone (a typical user) looking to, for example, ditch the Adobe ecosystem for a FOSS alternative (for ethical or other reasons) might pass on DT because of the frustration/confusion of the XMP files being created in their working dirs with no explanation.
the fine documentation would have explained that to you.
afaik: there is no provision for the xmp files to be stored/accessed automagically in any other location.
re-importing the file will attach it's edits from the library.db provided the file name is the same
I assumed something like that is in place already. I'm mainly speculating on the "what ifs".
the fine documentation would have explained that to you.
I sought out the docs, and learned the feature, but not everyone would. I'm talking from a UX standpoint. A change in wording to a tooltip may not seem like much of a difference, but if it meant retaining an extra 0.1% of users who don't read docs, maybe it's worth the trouble?