Delete photos option should be easily accessible

Bug #704482 reported by Bartek Celary on 2011-01-18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Rapid Photo Downloader
Damon Lynch

Bug Description

This is a wish-list bug (gui related)

I am often using RPD to get pictures from other people's cameras (RPD is extremely handy here as it can sort pictures based on camera type and make). Normally I keep the "delete photos" option enabled. I wouldn't wont to delete photos from other people's memory cards however. It is a bit cumbersome to enable/disable this option. Another issue is that you are not sure what will happen to the pictures as there is no visual indicator of the mode shown. Wouldn't it be better to have it somewhere in a more accessible place? File menu? A tick on the bottom of the list (next to download buttons)? The additional benefit is the fact the you see the option is on which might be important if the card you are getting pictures from is not yours...

Related branches

Damon Lynch (dlynch3) wrote :

This is an interesting observation. You definitely have a good point here - the feature is not as user friendly as it could be. These are some core python philosophies which help guide me in the program design, and I think in this case you've identified that "explicit is better than implicit" is not being followed as well as it could be:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Special cases aren't special enough to break the rules.
Although practicality beats purity.

Another way to think about it: when a camera has never been seen before, the program could pop up a warning dialog that auto delete is enabled. Please think about such scenarios in the context of different workflows, and then how you envisage such a feature. Please add it to this bug report.

Changed in rapid:
status: New → Triaged
importance: Undecided → Wishlist
Bartek Celary (karaphka) wrote :

OK, you have bunch of cards you grab pictures from. Some should not be cleared upon completion some should, some of them are yours (i.e. you use them regularly), some are used only once or rarely.

So to summarize, your idea is a good way to solve this. But considering the above mentioned scenarios, it could be good to modify the following option in preferences:

  [x] Delete photos and videos upon....:
  (.) always delete after download
  (.) ask what to do for a new card and save the choice (first time download)

You could also add a button in the preferences to clear those saved cards and that should be it.

What do you think?

Damon Lynch (dlynch3) wrote :

Thanks for thinking this through. Some points:

I don't know how to identify one memory card from another, but identifying a camera based on exif information is certainly possible. Some cameras even record their serial number in the exif, so it is possible to differentiate between two different cameras of the same model. Therefore I think it should be on a camera basis, and not a card basis.

I like the Gnome approach of trying to arrive at sensible default options, and not overwhelm the user with too many configuration choices. Personally I think if the auto-delete function is on, Rapid Photo Downloader should always ask the user if it should automatically delete photos that were taken by an unrecognized camera. And yes, there should be a way to clear that list of recognized cameras.

Your thoughts?

subeditor (subeditor) wrote :

Why we need to identify card? If I get Bartek right, he talks about manual control of files deletion. Program must NEVER decide what pictures should be deleted.
We just need some checkbox or other control (delete or not) at program face (not in prefs).

I'd like to see this feature somehow connected with this request -

Bartek Celary (karaphka) wrote :

We are trying to figure out the best way to handle the delete-upon-successful-finish option. So I don't think there's much connection between deleting selected pics by looking at the preview (the bug you are referencing to) and this bug.

The way I am grabbing pictures by default is that to every day-folder (like YYYY-MM-DD) I am adding the short camera model name and the serial number (if available). This is fantastic when getting pics from different cameras (even from the same card or a folder I would like to tidy).

I think that looking at the camera model could be misleading when you don't have a serial number available... In such case you could end up deleting pictures of a different camera but the same model you would like to leave untouched... Another issue is the lack of exif for movies which wont work at all for this. The question is: is there a way to identify files (both films and pictures) that point to the specific camera. I don't think this is possible. However there's something called UUID for partitions. Could this be used to identify the cards. Not sure if the volume serial numbers are random enough for this.

Damon Lynch (dlynch3) wrote :

The other issue is that recently the gnome code to access partitions on devices like cameras has not been working as expected, so I don't know if we can trust it for something as important as the automatic deletion of images.

It might be that a simple choice between "move" and "copy" on the main program window might be the simplest and easiest solution.

Suggestion for solution:
In the screen "Device|Size|Download progress", would it not be easy to add a narrow column titled "Delete?" containing a checkbox per device? Checked = files will be moved; unchecked = files will be copied. Or be even more specific and put both of the "copy" and "move" choices into each line of the table.

Bartek Celary (karaphka) wrote :

Thumbs up for Torben's suggestion. Clear information about what will get moved/copied/deleted.

Damon Lynch (dlynch3) on 2011-11-14
Changed in rapid:
assignee: nobody → Damon Lynch (dlynch3)
milestone: none → 0.4.3
status: Triaged → In Progress
Damon Lynch (dlynch3) wrote :

I think the best way to handle this is with a toolbar (actually, in this case, 3 vertical toolbars). You can see the attached screenshot. It's not as nice looking as before, but it exposes some useful functionality.

Damon Lynch (dlynch3) on 2011-11-18
Changed in rapid:
status: In Progress → Fix Committed
Damon Lynch (dlynch3) on 2012-01-08
Changed in rapid:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers