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 647048 - Should emit a bell sound when delete is pressed?
Should emit a bell sound when delete is pressed?
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: Trash
3.4.x
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 647225 648088 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-04-07 15:19 UTC by D.S. (Spider) Ljungmark
Modified: 2016-12-05 13:43 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description D.S. (Spider) Ljungmark 2011-04-07 15:19:50 UTC
Seems there's a regression when deleting files. Previously you could mark the files with the cursor keys and press delete to move files to trash, or shift-delete to delete them completely.   In 3.0, you can no longer delete files without using a right-click menu.

Pressing the delete key gives no visual feedback, no complaints at all, it just refuses to delete files unless you use a mouse.
Comment 1 Cosimo Cecchi 2011-04-07 15:30:49 UTC
The keyboard shortcut has been changed to Ctrl+Delete for 3.0.
Comment 2 D.S. (Spider) Ljungmark 2011-04-07 16:35:29 UTC
Why isn't there a visual feedback that delete does nothing then?
And, Can we also please make shift+delete into ctrl+shift+delete so we don't press that by mistake when trying to remember which key combination it is to delete files with?
Comment 3 Cosimo Cecchi 2011-04-07 18:08:33 UTC
(In reply to comment #2)
> Why isn't there a visual feedback that delete does nothing then?

What kind of visual feedback would you expect?

> And, Can we also please make shift+delete into ctrl+shift+delete so we don't
> press that by mistake when trying to remember which key combination it is to
> delete files with?

Well, Shift+Delete is protected by a confirmation dialog anyway...to be fair I've been thinking of changing it to Ctrl+Shift+Delete mostly for consistency, but I'm still not 100% convinced.
Comment 4 D.S. (Spider) Ljungmark 2011-04-07 18:17:13 UTC
I'd usually expect a "shaking window" effect on erroneous entry, especially when it's from a keybinding that has worked, and doesn't work anymore.
Comment 5 Cosimo Cecchi 2011-04-07 18:31:18 UTC
(In reply to comment #4)
> I'd usually expect a "shaking window" effect on erroneous entry, especially
> when it's from a keybinding that has worked, and doesn't work anymore.

Shaking windows are not part of the GNOME interface :) What we could do is emit an alert sound, but I need to think a bit more about it; changing the bug description to reflect this, and reopening.
Comment 6 D.S. (Spider) Ljungmark 2011-04-07 20:02:02 UTC
I'd rather say a feedback about removed shortcut keys.  Hotkeys/Shortcut keys are part of the human public API, and should be deprecated with great care ;)
Comment 7 Cosimo Cecchi 2011-04-07 20:26:09 UTC
(In reply to comment #6)
> I'd rather say a feedback about removed shortcut keys.  Hotkeys/Shortcut keys
> are part of the human public API, and should be deprecated with great care ;)

Well, Ctrl+Click was introduced really to avoid spawning a dialog, but to make it hard to trash a file by mistake, or not on purpose, so we're definitely not going to have a dialog for the feedback :)

I know most people don't usually look at the documentation, but the new behavior is actually documented in the Help guide.
Comment 8 D.S. (Spider) Ljungmark 2011-04-07 20:40:10 UTC
What I mean is, muscle memory and conventions are part of an exposed Human ABI as much as exported function names, removing them without warning is going to cause traction. I dislike having non-visible things change beneath my hands when there is little to no discoverability behind it.

Documentation is all well and good, but I don't see that coming up when I press delete either ;)
Comment 9 Cosimo Cecchi 2011-04-08 21:21:42 UTC
*** Bug 647225 has been marked as a duplicate of this bug. ***
Comment 10 Maciej (Matthew) Piechotka 2011-04-08 22:00:56 UTC
(In reply to comment #7)
> I know most people don't usually look at the documentation, but the new
> behavior is actually documented in the Help guide.

If something worked in UI through soft and hard Feature, UI, String and Code Freezes the documentation is the last thing I'm looking in. I may miss something but I would not expect any significant change between 2 last releases during hard code freeze. 

PS. I would argue that Delete key is very far from normal operation of human hand on keyboard. I heard many stories about computers that done things "on their own" but I've never heard about disappering files...
Comment 11 Cosimo Cecchi 2011-04-08 22:19:51 UTC
(In reply to comment #10)

> If something worked in UI through soft and hard Feature, UI, String and Code
> Freezes the documentation is the last thing I'm looking in. I may miss
> something but I would not expect any significant change between 2 last releases
> during hard code freeze. 

Yes, this has been a last-minute change for 3.0 (approved by the release team of course); on the other hand, 3.0 was an unique occasion to change this behavior (we wouldn't have probably done the change at all in another "normal" release).

> PS. I would argue that Delete key is very far from normal operation of human
> hand on keyboard. I heard many stories about computers that done things "on
> their own" but I've never heard about disappering files...

See [1] for a long thread on nautilus-list that triggered the change, or just google for "nautilus confirm trash" or something similar; not sending files to trash directly when pressing Delete has been requested multiple times in the last few years by a large number of users.

[1] https://mail.gnome.org/archives/nautilus-list/2011-March/msg00018.html
Comment 12 Maciej (Matthew) Piechotka 2011-04-08 23:04:43 UTC
(In reply to comment #11)
> Yes, this has been a last-minute change for 3.0 (approved by the release team
> of course);

I know - I did my research (let's just say that if it wasn't approved I would point it out ;) ).

> on the other hand, 3.0 was an unique occasion to change this
> behavior (we wouldn't have probably done the change at all in another "normal"
> release).

To be honest - I don't see why not. Gnome have gone through large change in behaviour in past (like nautilus opening in same window/new windows by default).
 
> See [1] for a long thread on nautilus-list that triggered the change, (...)
> [1] https://mail.gnome.org/archives/nautilus-list/2011-March/msg00018.html

I see. I don't see it a big problem for me (it is not so large change anyway) and I agree with undo is way to the future. I was just surprised that it have gone through hard code freeze. 

Anyway - I suspect that this's going to have much larger number of duplicates....
Comment 13 D.S. (Spider) Ljungmark 2011-04-11 07:05:28 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > I'd usually expect a "shaking window" effect on erroneous entry, especially
> > when it's from a keybinding that has worked, and doesn't work anymore.
> 
> Shaking windows are not part of the GNOME interface :) 


I just realised that Shaking Windows indeed is a part of the GNOME interface. It's already implemented in the Screen Lock dialogue when you enter the wrong password,  so there is current precedent for just when the user does wrong entries.
Comment 14 Cosimo Cecchi 2011-04-11 15:20:30 UTC
(In reply to comment #13)

> I just realised that Shaking Windows indeed is a part of the GNOME interface.
> It's already implemented in the Screen Lock dialogue when you enter the wrong
> password,  so there is current precedent for just when the user does wrong
> entries.

Right; that's a totally different use case (entering password vs. pressing a key with no keybinding attached), and it's not an application, but a system service.
Anyway, we're not going to add that effect to nautilus.
Comment 15 Stefano Teso 2011-04-16 08:30:33 UTC
(In reply to comment #6)
> I'd rather say a feedback about removed shortcut keys.  Hotkeys/Shortcut keys
> are part of the human public API, and should be deprecated with great care ;)

That's exactly why the move from Del to CTRL+Del was done in 3.0, which represents a fresh start, and not in 2.x :-)

Consider that the trash keybinding is already listed in the 'Edit' menu, along with all other keybindings, so it's not undiscoverable, Adding audiovisual feedback to a keybinding that probably people won't use in 2 months from now doesn't make much sense to me.

However, I'd say that instad of adding feedback to a no-op key press, we should probably play a sound effect on CTRL+Del. That would be much more informative, at the cost of maybe annoying the user after a while.
Comment 16 Cosimo Cecchi 2011-04-18 13:55:37 UTC
*** Bug 648088 has been marked as a duplicate of this bug. ***
Comment 17 Xavier Claessens 2011-04-18 14:15:39 UTC
I guess whatever I can say, this won't be reverted? Can we at least add yet another dconf options for this?

The context menu on a file does not even show the ctr-del shortcut! How are people supposed to discover this?
Comment 18 ecyrbe 2011-04-26 00:09:43 UTC
I do agree with xavier, at least, the context menu should advertise that ctrl+del is the shortcut to move a file to the trash.
Comment 19 ecyrbe 2011-04-26 00:51:32 UTC
i opened Bug 648658 to suggest another mecanism to solve this kind of issue.
Comment 20 Richard Schwarting 2011-04-26 06:29:02 UTC
If there was going to be feedback, perhaps we could have a notification bubble when someone presses just Delete on a highlighted file that just indicates
"Hold Ctrl and press Delete to remove files".  

Having my window shake at me would just be annoying.  "What do you mean?  I'm just deleting garbage! This works on every other OS and I've used and did last week, WHAT'S GOING ON!?"  A notification bubble would be a nice and obvious reminder.
Comment 21 Jeremy Bicha 2011-05-02 00:59:52 UTC
I believe this the wrong design decision. It seems to me like it would be more likely to accidentally hit Shift+Del when you're aiming for Ctrl+Del. (That assumes that the user can remember the difference between those two commands.) Even changing the permanent deletion keybinding to Shift+Ctrl+Del faces a similar problem in that it is possible to accidentally hit Shift+Ctrl at the same time.

I believe the correct solution, as discussed in https://bugzilla.gnome.org/show_bug.cgi?id=648658 is to revert this change and make it easier to Undo deletion with a modeless popup similar to what's used in Gmail with the Undo lab turned on or in modern web browsers that give the user the option to save the password for the site they just logged into. This should fix the accidental deletion problem and not overly frustrate users who've had decades of using certain keyboard shortcuts.
Comment 22 Bruce Pieterse 2011-05-21 20:26:52 UTC
I think António's comment (no 4) from http://blogs.gnome.org/xclaesse/2011/04/25/one-week-with-gnome3/comment-page-1/ should be used.
[...]
I think the best solution would be displaying a notification “_______ is being moved to trash. [Cancel]” and then “_______ was moved to trash. [Undo]“. I think thats a much better solution because:

1) You get a notification – so the file operation won’t be unnoticed.
2) The notification is not intrusive – unlike the “Are you sure?” dialog.
3) You get a way to cancel/undo the file operation.

That is already the Gnome Shell behavior for adding and removing Apps form the “favorites” in the dash. That’s also what Gmail does.

“Be considerate and forgiving
It is better to offer to undo a mistake than to ask a user if they are “sure.”"
https://live.gnome.org/GnomeShell/Design/Principles
[END]

The default delete behavior can be restored if the above is implemented and (advanced) users still have the CTRL+DEL option to bypass the notification completely. I personally feel that Del is quicker than Shift+Del when dealing with one or multiple delete operations. 

I would like to extend the functionality which can be released in a different version (3.2) or the next fix, which is to have a progress bar in the notification dialogue for larger file operations with a cancel/undo button as well.

Keep up the great work! :)
Comment 23 Alessandro Capogna 2011-12-13 13:21:14 UTC
I agree, this is a wrong design decision (like the one to hide shutdown/restart on the menu). Please, think also to users who use everyday a different OS / DE.
Just like cars (for example), tools like DE must implement the de facto standards. Think about what would happen if the cars manufacturers of different brands decide to use pedals to turn, another decide to use the wheel to stop...
Keep the de facto standards is also a good way to help new users to quickly  use-appreciate gnome (considering they are probably coming from another OS / DE).
Please, restore it (or, at least, put the possibility to change it in the keyboard shortcut). Thanks a lot
Comment 24 Xavier Claessens 2012-07-18 16:25:14 UTC
To make things worse, now in nautilus 3.5.4 the new menu does not even mention the ctr-del shortcut. I was already not intuitive and really hard to discover, but not it's even IMPOSSIBLE to discover. Well done guys.
Comment 25 Cosimo Cecchi 2012-07-18 16:32:58 UTC
(In reply to comment #24)
> To make things worse, now in nautilus 3.5.4 the new menu does not even mention
> the ctr-del shortcut. I was already not intuitive and really hard to discover,
> but not it's even IMPOSSIBLE to discover. Well done guys.

Thanks. That's a GTK bug.
Comment 26 André Klapper 2012-08-01 09:24:07 UTC
(In reply to comment #25)
> Thanks. That's a GTK bug.

Cosimo: Is there a bug number to follow / a dependency number to set in this report?
Comment 27 Cosimo Cecchi 2012-08-01 10:25:59 UTC
It looks to me that what Xavier mentions in comment #24 has nothing to do with this bug report, but I filed https://bugzilla.gnome.org/show_bug.cgi?id=680962 against GTK for it nevertheless.
Comment 28 nodiscc 2012-08-01 13:56:50 UTC
Ok this (emitting a bell sound when del alone is pressed) works for me in list view, but not in Icon and Compact views (nautilus 3.4). 

To be fair, I already have expressed my point of view and propositions on the Ctrl+Del change in https://bugzilla.gnome.org/show_bug.cgi?id=648658#c56 and https://bugzilla.gnome.org/show_bug.cgi?id=648658#c57 and despite the obvious amount of useless user rage in bug 648658, there are many valid points in the comments, this has to be reverted. This would close bug 647048 and bug 648658 and maybe other bugs. Why not revert it and see if someone reports a "file deletion shortcut should be ctrl+del"? No taunting intended
Comment 29 Alexandre Franke 2016-12-05 13:43:59 UTC
Del now moves files to trash, the bell is not needed anymore.