Review Request: Add a confirmation window when emptying the trash

[Ingo Klöcker]

On Tuesday 30 March 2010, David Faure wrote:
> > On 2010-03-29 14:55:47, Tom Albers wrote:
> > > Why is this needed? It is emptying the trash, so the user deleted
> > > the stuff first already. I see no need for another confirmation
> > > and another dialog. It is already a 2 step action to delete
> > > something permanently.
> > 
> > Nicolas Lécureuil wrote:
> >     This is a security, because emptying a trash is not an actions
> >     w/o consequences and the user can have asked to not beeing
> >     warned when deleting files. We use an "Don't ask me again"
> >     option so the window isn't shown anymore if this annoy the
> >     user.
> >     
> >     I think this is a usuability improvement.
> >     
> >     On kiorc we have :
> >     
> >     [Confirmations]
> >     ConfirmDelete=true
> >     ConfirmTrash=true
> >     
> >     One to ask or not when deleting files and one to ask or not
> >     when emptying the trash.
> > 
> > Will Stephenson wrote:
> >     I agree with Tom, this is bloat.  By default it is a 3 step
> >     action to permanently delete a file via the trash can. 1)
> >     invoke Move to Trash action
> >     2) Confirm moving to Trash
> >     3) Empty Trash
> >     
> >     You are adding 4) Confirm Empty Trash, because the user might
> >     have already disabled 2).  This makes the default path to
> >     permanently delete something a 4 step process which is
> >     excessively cautious.
> >     
> >     If the user checks "Don't ask me again" on 4), then we are back
> >     to a 2 step process again, and your next patch adds 5) Confirm
> >     Confirm Empty Trash - this can go on forever.
> >     
> >     If you consider the Delete action as well, this remains a 2
> >     step action to permanently delete 1a) File->Delete
> >     2a) Confirm deletion
> >     
> >     So considering that the user might configure Delete instead of
> >     Trash in Dolphin, and might disable 2a), your patch still does
> >     not add any additional safety, at the cost of making the
> >     default configuration excessively cautious.
> 
> I don't really agree. The action of emptying the trash can happen
> completely independently from steps 1) and 2). So counting the
> number of overall steps doesn't really mean much in real life.
> Typically you trash many files, and then you later empty the trash
> once e.g. when out of disk space; so it doesn't happen as often, and
> it's the actual 'dangerous' operation in all this (no undo).
> 
> I believe that the point of this additional confirmation is that
> slightly clumsy users might hit "empty trash" by mistake, while they
> in fact were looking for how to get stuff out of the trash, or might
> later.

Exactly. Maybe the user really wanted to select "Copy" or "Rename" 
instead of "Empty Trash Bin". Both options are directly above/beneath 
"Empty Trash Bin" in the context menu and they are not even separated by 
a separator.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100330/916cbf9e/attachment.sig>