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?
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).
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.
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.
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.
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.
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.