When I import a single image, by default it opens in darkroom. Is it possible to disable that – Just import, nothing else? I’ve looked through preferences but nothing caught my eye.
When I remove or trash an image from darktable, it doesn’t remove its sidecar. I understand the potential value in keeping sidecars, but there are also times I’d like to delete them upon removal (e.g., when it’s truly a delete-worthy image). Is that an option? I am creating sidecars only upon editing, BTW.
Question 1: No, you cannot. This behaviour was introduced in, I think, version 3.6 and it is really annoying that it cannot be changed in the preferences. I’ve mentioned this multiple times when it was developed and it fell on deaf ears. Maybe you can file a FR on GitHub.
Question 2: You use the words remove, delete and trash in your question and they have different meaning for darktable in this context. Not sure what it is, exactly, what you like to have or are looking for.
When using the remove button you only remove the image from the database and the associated xmp file is not removed. The RAW itself is also still on your disk.
If you use the delete button the RAW and the associated xmp are deleted from your system. Both database and disk.
There’s also the ability to (not) use the trash facility of your OS (don’t think this one is applicable here).
I understand your needs but don’t forget that we also have users that complains about too many options because many times developers introduce such options to please different use cases.
So, it’s hard to deal with adding options and not have too many because some users became lost by the multiple options in darktable.
Yes, I’m referring to both remove and delete in the ways darktable uses them. If I simply make darktable “forget” the image exists or if I actually have darktable delete it from the filesystem, in neither case am I interested in saving the sidecar, so the option to remove it would be handy. If the sidecar was worth keeping, I almost certainly wouldn’t have removed nor deleted the image in the first place.
I spent about an hour last night deleting orphaned sidecars (their progenitor images had been deleted) and that was only for a few folders. A more automatic way of clean up would be nice.
I had a, roughly, similar issue, orphaned darktable and sometimes RawTherapee sidecars, due to the fact that my test image folder tree is shared by both RawTherapee and darktable versions and the way I test stuff. I created a script that runs from cron every morning on my Linux box to take care of this.
You might want to spend a bit of time creating something similar on your Windows machine. Not an ideal solution, but it does the job, is fast and it prevents making mistakes compared to doing it by hand.
It might still be an idea to file a FR on GitHub, though. I do agree, in general, with @Nilvus about the need to be cautious about the amount of options, but if there is enough traction for a specific one it should(?) be added to the preferences in my opinion.
While I agree that when you decide to delete a file, its associated sidecar should also be removed (*), and I think that’s what happens (at least with 3.8.1 under linux)
I’m in two minds about removing sidecars when removing an image only from dt’s database: you may have other programs using the sidecar (DAM programs come to mind), in which case you do not want the sidecar removed, keeping in mind that the base file is kept on disk as well.
Sorry, I have no idea how to automate deleting orphaned sidecars under windows. Under linux, a bash script would be able to do the trick :
for each <file>.xmp, check if <file> exists, if not, delete <file>.xmp
but that would mess up things if you use duplicates (where there is a suffix added to the basename
(*: It’s actually a bit more complex than that:
if an image has not been edited, you want to remove the base file and sidecar
but after an edit, there might also be duplicates, so you can’t just remove the raw file when deleting an image…
I agree, scripting is much more straightforward and easier on *nix. Don’t even mention PowerShell… My current laptop came with Windows so that’s what I’m using (for the time being at least), but prior to that I almost exclusively ran Linux at home for the past 6-7 years (first CentOS then Xubuntu). Before retiring a year ago, Linux / Solaris admin was one of many hats I wore. I can’t count how many shell (and very occasional Perl) scripts I wrote over more than two decades. Not that I’m an expert by any means, but it’s a handy tool that I greatly miss on Windows. A semi-stopgap ‘solution’ is to write a shell script in WSL that touches the Windows volumes. Hmm…
Actually, I think an option to delete sidecars would be handy, not a requirement. A checkbox on the confirmation dialog would suffice, and it could default to ‘no’. It would be cleaner to make those decisions at remove-time, than weeks / months later.
I think adding options that visibly exist only in the Preferences dialog really isn’t a problem, especially if they’re “hidden behind an Advanced button”, as it were. It would be read / understood / configured only once. As I recall, that was a basic tenet of the ‘discussions’ between mosfet and Havoc Pennington years ago re: basic philosophical user-facing differences between KDE and GNOME. I agree with mosfet - Provide detailed options, but put them behind an Advanced button so the more casual user doesn’t encounter them unless they’re digging. I wouldn’t be offended even if had no GUI interface and was configured in darktablerc only.
I am almost certain there is a script offered in one of the threads here from the last couple of years that looks through a dir and finds xmp files that have no matching raw file…you can make a list or delete if I recall?? Now I just have to recall where…
You are correct, I just confirmed the sidecar was deleted when an image was trashed.
While I use dt (obviously) for raw editing, I don’t really use it much for routine image management nor simple viewing. On my computer, XnView, FastStone, etc. all run much faster. As a result I don’t do a lot of image clean up with dt. So I guess for the time being I can use other software to identify images to delete, then use dt to trash them and it’ll clean up the sidecars. At least for those I’m deleting.
There’s a related issue here. Not long ago a preference setting was introduced so that sidecars would only be created once you started editing. This is good and cuts down on clutter. However if you hit “discard history” for a raw with no sidecar, dt creates a sidecar! Surely this is wrong, there’s no point in creating one. (Why discard history if you’ve not started editing? - well you may have a whole bunch, some edited, some not, you decide to select all and discard history…) Why not go a step further and say that if you discard history and the xmp is present then it will be deleted?
[above based on current Master]
For you. We have had complaints about the fact that darktable is not easy to use/understand. And one main reasons is that there’s too much options and possiiblities. And they don’t help new users to learn darktable. I don’t talk about what I think here but what feedback we had.
About what I think is that there’s a limit on all things in life, even options in an app. So I completely disagree here: there’s sometimes too much options. What is always hard is to decide when is too much and when is not. And I’m quite sure that not only people could decide/know that. It’s all about compromise between different things to consider and different views. We can’t please everybody.
My current laptop came with Windows so that’s what I’m using (for the time being at least), but prior to that I almost exclusively ran Linux at home for the past 6-7 years (first CentOS then Xubuntu). Before retiring a year ago, Linux / Solaris admin was one of many hats I wore. I can’t count how many shell (and very occasional Perl) scripts I wrote over more than two decades. Not that I’m an expert by any means, but it’s a handy tool that I greatly miss on Windows. A semi-stopgap ‘solution’ is to write a shell script in WSL that touches the Windows volumes. Hmm…