After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 417500 - Deletion of pictures
Deletion of pictures
Status: RESOLVED FIXED
Product: f-spot
Classification: Other
Component: General
0.2.2
Other All
: Normal enhancement
: ---
Assigned To: F-spot maintainers
F-spot maintainers
: 353056 537453 569747 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-03-12 15:29 UTC by Jean-Christophe Berthon
Modified: 2009-11-20 08:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add a trash to f-spot (7.82 KB, patch)
2007-10-21 16:53 UTC, michael.wiertlewski
none Details | Review

Description Jean-Christophe Berthon 2007-03-12 15:29:34 UTC
Even though I perfectly understand the reasons (and even like) that when one presses the Del key for a picture or group of pictures, it only removes the picture or set from the catalog but not from the hard disk. This feature is extremely confusing for common people. This is not a f-spot only issue, but this is an issue for all this kind of software like iTunes, iPhoto, etc.
The only solution to reconcile computer enthusiast and common user is to have those software behave as a common user would expect it. But, there would be an option for the enthusiast to change the behaviour to what it is now in F-Spot.
In other word, by default F-Spot should not manage a catalogue of files on the hard disk, but the files directly. The user can change this behaviour in the options. To educate the user, a solution like the one used in Azureus which displays a small wizard after each software updates to set a few main parameters is heavily recommended.

Other information:
use case (current state)
  - Sarah imports photos from a digital camera to F-Spot. A few ones were boring and she suppresses them by pressing the delete button. Later on, she wants to send one of those picture as an e-mail attachment. She browser through here directories and find out that some old photos she did not like and she had thought deleted are still there. (optionally she gets upset and says the tool is crap) :-(

use case (proposed new behaviour)
 - Lea install the new F-Spot and launch it. A wizard ask her a few questions about her usage of F-Spot and if she wants to have f-spot as a image catalogue or as a file manager. She is a photograph enthusiast and prefers to have a image catalogue so her precious pictures are not handle directly by f-spot and always a copy is used for modification.
 - Sean is completely new to photography and to computer. A friend of his has installed Linux <your distro name> and it comes with F-Spot. He launches it, a few question are asked and he chooses the recommended answer (a.k.a. "file manager mode"). Being completely new to this, he won't use another software to modify his photograph but rather the editing tools of f-spot. He expect that each photo is directly modified or deleted from his hard disk. So when he wants to send one by e-mail he knows which one to find.
Comment 1 Thomas Van Machelen 2007-03-12 15:44:35 UTC
Dear,

Thanks for your extensive enhancement report.  Some remarks:

1. This bug might already fill some of your needs as it is about adding a shortcut for deleting from disk: http://bugzilla.gnome.org/show_bug.cgi?id=301151
2. I generally think that popping up wizard the first time the user opens an application is not a "good thing to do".  Asking questions about deleting images the first time seems like a strange thing because you don't know how the program behaves, heck, maybe you don't even know what the program is intended to do.  Why would you know at that time you want f-spot to delete instead of remove from catalog if you press del?
Comment 2 Jean-Christophe Berthon 2007-03-12 17:46:13 UTC
I was trying to propose a rough solution, but I did not make any investigation towards users if they like that or not.

As for your points:
1. the problem I sense with the short-cut is that a common user will still press "del" and expect the picture to be deleted from the hard disk (or actually moved to the trash bin) and it will not understand why when he is browsing his files (via Nautilus) pressing the del key put the file in the trash bin, a why when doing the same thing in F-Spot it will not do so. As a computer scientist, I understand the difference, but a user will not. So he will not find out the Shift+Del combination. I think for a geek like me ;-) this would fit, but not for my parents...

2. For the wizard thing, Azureus is using it and also iTunes (but only after the 1st install). So it seems that it could be a reasonable solution. But if I'm sure that for people like me it is OK, I'm uncertain that it would fit others. This would be an interesting study to perform, I don't mean that we should see if a wizard is good or not (that would be biased) but a real ergonomic study to see how we should address the problem with the normal users. But I'm not an ergonomist, so I cannot make such a study.

N.B.: as said, this is a problem that many solutions (commercial or not) are facing.
Comment 3 herber 2007-03-14 08:00:58 UTC
I have run into the delete problem.  Another part of the solution might be to place 'deleted' pictures into a trash bin along with all the meta data.  One of the configuration options, and a wizard question, would ask when 'trash' photos should be deleted, immediately, at the end of the session, or only when the empty trash option is selected.

Tivo has a new feature that we could emulate.  They no longer ask you to confirm TV show deletes, they just put them into a deleted area.  You can scan that section and restore any that you want or you can really delete them. If you don't delete them, they age out as new shows are recorded.  F-Spot could monitor the disk free on the Photo partition and start deleting when either space is limited or when the deleted area exceeds a user set threshold.
Comment 4 michael.wiertlewski 2007-10-21 16:53:15 UTC
Created attachment 97568 [details] [review]
Add a trash to f-spot
Comment 5 michael.wiertlewski 2007-10-21 16:54:45 UTC
Comment on attachment 97568 [details] [review]
Add a trash to f-spot

Hi all,

First sorry for my bad English.

I use F-spot for a while and the Del key was upsetting me. Because I am the typical "Sean" user (has Mr Berthon said), when I press the Del key i want to put the selected pictures in the garbage bin.

I think f-spot behavior doesn't fit with users who don't have a large Hard Drive.  I suppose that even professional don't keep every pictures.

That why I developed a patch to add a trash for f-spot based on a special tag named (guess what) Trash.

It's based on the latest f-spot version from SVN

Tell me what you think about it.

Cheers
Comment 6 Maxxer 2007-10-22 10:35:51 UTC
Shouldn't trashed pictures be hidden to normal browsing? 
Comment 7 michael.wiertlewski 2007-10-23 18:26:26 UTC
Sure, that's was my first idea.
But my skills in f-spot development are limited.

I'm going to look for a solution.

I wanted a small impact on f-spot code, so i used tags and things like that.
I tried with the Hidden tag, but it not real time. When you tag a picture with Hidden tag it only desapered when you refresh the picture set.

If you have a concrete idea, tell me.

I'm trying to do something better, i'll post it soon.

See you
Comment 8 Maxxer 2007-10-23 19:09:39 UTC
I thought about the Hidden tag too. 
Using that, maybe when a picture is sent to trash you could refresh the actual query. This way hidden pics should go away.

But then, IMHO, when Hidden tag is selected you shouldn't browse trashed pics. And again when browsing hidden, don't show the trash.

I don't know, but maybe it could be considered a bit dirty solution.


I'm not such a good dev, but if you need help try do ask. I'll be glad to help if I can.
Comment 9 Stephane Delcroix 2007-12-10 11:37:25 UTC
*** Bug 353056 has been marked as a duplicate of this bug. ***
Comment 10 Maxxer 2008-06-10 05:59:01 UTC
*** Bug 537453 has been marked as a duplicate of this bug. ***
Comment 11 Jean-Christophe Berthon 2008-08-05 21:19:10 UTC
Michael had a good idea. A possible solution would be to use a trash bin inside f-spot (just like iPhoto I think). So when the user press the Del key on a picture or a selection of them, they are not yet deleted from the hard drive, but they are moved in f-spot to a trash bin.
The user can empty the trash bin and the picture are then removed from the hard disk (or actually moved to the system trash bin).

IMHO, f-spot should not use the system trash bin, but have an internal version of it.
Comment 12 Maxxer 2009-01-30 07:25:20 UTC
*** Bug 569747 has been marked as a duplicate of this bug. ***
Comment 13 Dotan Cohen 2009-01-30 13:24:37 UTC
> IMHO, f-spot should not use the system trash bin, but have
> an internal version of it.

No, imagine if each application had it's own trash bin? That would be absurd.

Have F-Spot move the photo file to the Gnome trash bin, and store the photo's metadata with a "trashed" flag. If F-Spot detects that the picture was restored from the trash (based on filename or hash, however the devs see fit) then restore the metadata to the photo. The metadata of trashed photos could be purged after X time passes, or Y restarts, or Z foobars.
Comment 14 Jean-Christophe Berthon 2009-02-07 21:35:02 UTC
> No, imagine if each application had it's own trash bin? That would be absurd.

It is not absurd. It is used! :-) I mean iPhoto (the photo management tool from Apple on Mac OS X) is using an "internal" trash bin which is not the Mac OS system trash bin. I have been using iPhoto, and it is pretty easy.
In addition, this is not absurd because the Gnome trash bin is there for deleted files from the file system, this is at the operating system level.
When you are in an application, it can be that you do not delete a file but a data (a more abstract information)! For example with f-spot you have a RAW file, you transform it into a TIFF and/or DNG file (for long-term backup) and then you make 2 different JPEG one optimised for photo printing, one optimised for a website. You still want to manage them all as one entity (Adobe Lightroom or Apple Aperture does that pretty well), and when you delete you could want to delete the whole bunch or just one. And perhaps you want to restore the whole bunch as one entity. This information is application dependent, thus it is not absurd that trash management is hold at application level.

> Have F-Spot move the photo file to the Gnome trash bin, and store the photo's
> metadata with a "trashed" flag. If F-Spot detects that the picture was restored
> from the trash (based on filename or hash, however the devs see fit) then
> restore the metadata to the photo. The metadata of trashed photos could be
> purged after X time passes, or Y restarts, or Z foobars.

And if the user restore the photo and empty the trash bin, he does not come back to the previous state because f-spot cannot find the metadata...

I do not mean your idea is bad. I just only think a trash bin at the application level is better. But if someone has another proposal that still use the Gnome trash bin, I'm open.
Comment 15 Duncan Lithgow 2009-11-19 09:19:19 UTC
f-spot 0.6.1.5 now moves files to the users trash. please mark as fixed.