Bug 246726

There is a confirmation dialog as a default. It isn't shown if you selected this options in the dialog or in the settings of digikam. You can re-enable the dialog in the settings under Miscellaneous.

Simon, any good reason why we should close this bug as INVALID?

Simon, any good reason why we shouldn't close this bug as INVALID?

yes, for me it's INVALID...

Gilles

@Marcel, yes.
I don't know if many people have enabled the confirmation dialog. I don't want to confirm to delete a single image every time, I regard this as really painful.

However, when deleting many images at once, that's something different. 

When looking through photos after downloading them from the camera, you maybe press Del 100 times (and would have to confirm 100 times) to delete single pictures. Or you delete them all at once. Greater risk, and happens less often, so imho it is appropriate to show a confirmation dialog again there. (Perhaps with a custom number of images when to warn.)

Greater risk ??? I think no, because itels are sent to the trash. all can be restored. It's a security.

I manage a lots of pictures on my computer, i remove duplicates, wrong, dumy items. i never lost something important with current behavior...

All others tools dedicated to manage contents work like this. I never see a different workflow. 

Gilles Caulier

As long as it is not possible to restore pictures from the trash by deletion date, restoring from there is not so cool.

My point is: Deleting one or two images is not the same as deleting dozens. I guess nobody wants a confirmation dialog for single images. According to your reasonning it could be removed completely, as it anyway goes to trash where it can be restored again.

>As long as it is not possible to restore pictures from the trash by deletion
>date, restoring from there is not so cool.

Right. This is a good idea to improve trash management from KDE desktop. Please report this wish at the right place on KDE bugzilla.

Gilles Caulier

Seems like this should go to KDE Platform if the idea is to add something like:

Ask confirmation when
[  ] moving single file to trash
[X] moving multiple files to trash

I'm not sure. On the one hand about the 
[x] multiple files
— I would rather use a limit of, say, a dozen. A number of files you statistically delete only in 5 % of all cases, or perhaps in even less, such that the user does not have to confirm too often (I would immediately switch it off again). 
On the other hand about KDE; Since digikam is an app with a specific task where deleting a bunch of files may mean something quite different than doing the same in a file manager (like deleting an old drupal plugin directory with 50 files vs. deleting the most recent 50 pictures by accident).

Simon,

This file still valid using digiKam 2.4 ?

Gilles Caulier

Gilles,
    I tested on digikam 3.2.0 beta.It gives a confirmation dialog box for every image we delete by default.So is option of giving a confirmation dialog box when deleting X images be added or is this bug should be closed?

Saurabh,

Look like code relevant of a dialog box to ask to user about all items to delete have been commented here :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/utilities/importui/main/importui.cpp#L1935

The question is why ? Perhaps it's a side effect when Islam Wazery as ported Import UI code to Qt4 model/view (typically code have been commented for testing purpose and never re-actived)

Note : this dialog ask to users for all items to delete in one time. This is the right way to handle file deletion feedback. In opposite way, can you imaging if user want to delete 1000 items, it will must to press OK in a dedicated dialog for all items, one by one. It's not acceptable...

Please reactive this code and check if right behavior is respected...

Gilles Caulier

Gilles,
   I tried to test the patch and had to include "cameramessagebox.h" but when executing make command I get foll. error:http://paste.kde.org/719900/
It shows that "camerathumbsctrl.h" not found

I tried to google this problem and came across this link:http://community.kde.org/Digikam/GSoC2012/CameraUserInterfaceRevamp
It shows in TODO list that camerathumbsctrl class would be deleted and in digikam3.2.0 it is deleted so I could not build the code

Thus camerathumbsctrl should be added back or some other way(I don't know any) should be thought to solve this bug or this bug be closed for now

Ok, now i understand the problem and why this code is commented.

Previously Qt4 model/view port done by Islam during GoSC 2012, i implemented cameramessagebox dialog to be able to show items from camera where we want to process somethings (delete, download, lock, etc...). here KDE list items dialog cannot be used because camera items thumbnails are not easy to handle: it's not a simple KUrl to manage, especially with GPhoto2 devices.

This dialog been able to show camera items thumbnails. Like this users is able to judge that selected items to process are right, to prevent wrong operations.

To get camera thumbnails, i written a cache mechanism between computer and camera device named camerathumbsctrl. The dialog get thumbnails through this cache.

Since Model/View port, camerathumbsctrl have been removed and replaced by another code.

So we need to adapt cameramessagebox to use Islam implementation to get items thumbnails.

Note : I CC Islam for info...

Gilles Caulier

For me the current confirmation dialog that i tested with current implementation from git/master is enough to prevent accidental deletion. To add more options in this dialog to differentiate behaviors for some items, and a thousand of items will bloat GUI and confuse end users usability.

Gilles Caulier