Darktable 4.2.1 removes random files in place of needed ones

An unpleasant bug has been noticed in Darktable 4.2.1. When you try to delete a file from a photo collection with the Del key, Darktable deletes a completely different file. The selected file, however, remains in the collection. This problem occurs when there are a lot of files in the directories (about 20-30) and occurs about every 5th time the Del key is pressed.

did you check which image gets cursor focus before deleting?

Yes, the cursor is on the image. The image is highlighted with a white frame.
OS Ubuntu 22.04

Checked with a fresh install of git master 4.3.0+2373~g3feac11628 on Ubuntu 22.04.

  • Collection with 102 images
  • Removed single images (by hovering the mouse over the image)
  • Removed 2, 3 or 4 selected images simultaneously (mouse must be over one of the selected images!)

Not able to reproduce.

Del does not delete the images, it removes them from the collection.

I did some more tests. It turns out that when remove, it is important that the cursor is on the file you want to remove. Although you can navigate through the collection with the keyboard arrows. However, when you select a photo with the arrows and press the D key, the photo that was selected with the arrows opens, and the position of the cursor has no effect on it. When you select a file with the arrow keys and want to remove it with the Del key, the file will be removed, but only the one the cursor was on. This is very strange and illogical.


It is a feature called Act On.

It seems this “Act On” feature is causing many headaches. Wouldn’t it be wiser to automatically disable it when there are selected images? What exactly is the problem that “Act On” is meant to solve?

1 Like

There is a very long thread on GitHub about it. The feature tries to provide a quick way to perform actions when you use the mouse.

Seems to go against all UI standards out there , making it very unpredictable behaviour for most people out there . And on a function that removes info , seems quite a bad idea ?

I understand the idea and the workflow benefits , but it needs to be communicated better and be opt-in option i guess. Or a toggle button to enable ‘quick mouse actions’ that apply the action on the hoeverre entry instead of a selected entry. (Which has the opportunity to explain it clearly what the toggle changes versus default behaviour).

1 Like

Add comments to the GutHub issue or start a PR for consideration.

We should avoid these types of generalizations. We have no idea how many people use it, or even how many users we have.

The only way we’ll ever know if its “most people” is to change the behavior to the opposite and see how many turn up to complain.

Thanks for the hint what could be the problem.

We should avoid these types of generalizations. We have no idea how many people use it, or even how many users we have.

Why avoid true statements just because they are broad reaching? There are simply no established UI standards that act in this inconsistent way. Can anyone point to one?

The important question should not be how many current users are there, or how many current users have adapted to this behavior, but why is DT experimenting with new UI behavior and implementing it inconsistently? It would certainly seem to make getting used to DT harder for newcomers.

1 Like

You should read my statement again. I said we have no idea how many users we have, so we should not generalize “most users.” The statement might be true for you and others who voice your opinion here, but you’re assuming you’re the majority. But we can add or remove features based on that assumption.

There aren’t really too many UI standards, period. I’m not sure that darktable would care about them that much even if they did exist.

I don’t think this is an experiment, it has been this way for quite a while.

Doesn’t matter how long it has been this way. That just means it has been a long-running experiment. In the context of all desktop software, it is an anomaly. It is the only software I know that works this way. It differs from decades of software conventions. That’s why I call it an experiment.

1 Like

You’re free to call it whatever you’d like but your points fall far short of bring meaningful enough for change.

I don’t expect these comments to be sufficient enough to cause a change. I was just joining in others’ criticisms to show they were not isolated. Hopefully, others will chime in and help build a case.

You sure seem totally entrenched in the status quo, so I’m not going to belabor this any further. I do hope the DT team reconsiders some of the UI decisions by, at least, making them “opt-in” and configurable in the settings.

1 Like

Uh nope, I never said if I found this feature useful or not.

I don’t really use this feature, but it doesn’t bother me that its there. I don’t think it’d bother me if it were gone either.

I object to those who assume themselves to be the majority while having no way to know such things. I also object to making assumptions about others.

If you feel so strongly and have UI/UX chops, then you should join github and suggest improvements.

1 Like

I find this “Act On feature” very distracting in Darkroom with the Control-C Control V acting on the hover thumbnail instead of the selected picture. Maybe annoying is a better way to put it and I would love to be giving the option to shut it off…


Ya made me look! This feature or obstacle, depending on the user’s reaction to it, has no effect on me because the way I use darktable doesn’t involve collections at all. However, for those that do use collections, it does look like the doc could be clearer in relation to the OP’s complaint. The lighttable overview says:

“While the mouse is over an image thumbnail or images are selected, there are a number of actions you can perform with keyboard shortcuts: …”.

It doesn’t spell out what image is affected when the mouse is over a thumbnail and an image is selected, and deleting the image from the collection is not among the listed actions.

I can see how the “Act On feature” could provide somewhat quicker actions, for those that know it’s there, by avoiding the mouse clicks required to select images. However, in almost 50 years of using a wide assortment of user interfaces, I have never encountered another product that works this way. Absent “in your face” doc of the feature, I think it violates the principle of least astonishment and provides an opportunity for unexpected errors. I have no idea how many people take advantage of this feature, but it should be made abundantly clear that the feature exists and how it interacts with mouse-based selection. I’d suggest adding something to the doc about this that is lit up like the Las Vegas strip.