GNOME Bugzilla – Bug 326776
Have confirmation dialog for Move to Trash
Last modified: 2018-05-24 11:04:02 UTC
Several people have commented that they think a confirmation dialog for Move to Trash is needed, so they don't accidently use it. You can restore tracks by moving them from the trash to their original location, but this isn't easy, so a dialog may be warrented. The biggest issue I can see is that it would be annoying if you are "cleaning up your library": a) find a track you don't want, b) Move to Trash, c) say "yes I really want to". repeat. One potential solution would be for the dialog to have "don't ask me again" and/or "don't ask me again until I restart Rhythmbox" options. The latter could be handy since the majority of the time you are doing multiple deletes, it will be in a big batch.
I agree with the comment posted above, as I had recently 'moved' an item to the trash inadvertantly. This is not too difficult to do at the moment as both the 'delete' and 'move to trash' options are one above the other in the menu. A confirmation dialogue as suggested by James would be most useful, especially with an option to 'not be reminded'. Perhaps another possibilty would be to reword the delete option to read 'clear from library', or similar wording to make it clear that the two functions are different.
nautilus doesn't have a confirmation dialogue, I think it would be bizarre if Rhythmbox got one. The way it was done in nautilus was to have separators either side of it and a "wastebasket" icon for the menu item.
Created attachment 57401 [details] [review] patch This patch adds a separator to keep Move to Trash furthur away from other items. It also does the "Delete" -> "Remove" name change suggested in bug 326178. I agree with Bastien that consistiency with Nautilus would be good. If you do accidently move some files to the trash, you can just move them back again (RB will keep the rating and playcounts for up to a month).
Patch WORKSFORME.
Looks sane. I never liked having 'move to trash' so close to 'add to queue'. We should use the GTK_STOCK_DELETE icon for the 'move to trash' action so it looks the same as Nautilus. We could probably copy the action descriptions too, since they could stand to be clearer. Nautilus is somewhat wordy ("Prepare the selected songs to be copied with a Paste command" vs "Copy selection") though. I think we'd need separate Remove actions for library and playlists, since proper descriptions would be fairly different - "remove the selected songs from this playlist", "remove the selected songs from the library and all playlists".
Maybe we can keep a stack of lists of trashed items that we can "Edit/Undo Move to Trash"?
I've committed the patch, with the icon suggestion from comment #5. Separating out the library and playlist remove actions sounds like a good idea.
Created attachment 58108 [details] [review] change stock icons patch How about this instead?
Yeah, that is probably better.
(This is Debian bug http://bugs.debian.org/351808.)
The inherent problem with having this option available is that there's currently no "Restore" functionality in the GNOME Trashcan. Since deleting these files from Rhythmbox puts all the music files into the Trashcan without respect to directory structure, a carefully organized Music folder becomes dumped into one flat directory. I don't believe the analogy with Nautilus is appropriate, because with Nautilus, if you delete multiple objects, they're all from the same directory. The Trashcan still can't restore, but you can simply drag and drop all the items in it to the folder you just deleted them from. This does not hold true for Rhythmbox, which results in the hierarchy of files being irrevocably lost. If it is insisted that there be no confirmation dialog, which I can understand for consistency concerns, there needs to be an alternate solution. If the music is stored in the Library Location (as opposed to another folder added later), could the items be sent to the Trashcan along with the directories in their hierarchy up until the Library Location directory? An example would be if your Library Location is ~/Documents/Music, then deleting "~/Documents/Music/Franz Ferdinand/Franz Ferdinand/01. Jaqueline.ogg" would put the folders and file "Franz Ferdinand/Franz Ferdinand/01. Jaqueline.ogg" into the trashcan. Alternatively, the dialog could be put into place as a temporary measure until the Trashcan gains a "Restore to Original Location" ability (assuming this is planned or intended). While not the optimal solution in the long run (as this dialog would be removed once the requisite trashcan functionality is implemented), this could prevent many cases of loss of the music folder hierarchy. A third approach would be similar to what iTunes does. Have an option to remove a track from the playlist; when this option is selected, a dialog is displayed asking the user if he/she wishes to simply remove the song from the library, or delete it from the disk as well. However, this may also raise concerns about having a dialog that isn't consistent with the rest of Nautilus. The option could also be removed altogether. I'm not sure what the original need was to implement the option in the first place, but it's possible that the feature could be reexamined entirely; is deleting music that important a use case of the software, that it need to be implemented? If so, does it have to be done in the context-sensitive right-click menu? Since that should be reserved for the most common of use cases, why not remove the Delete ability from the right-click menu and instead have it only in the Edit menu? I think any of these suggestions would be far better than the current implementation; but that might simply be my own annoyance at having had this bug bite me. Thankfully, I have several backups so nothing was lost save some time and convenience. Still, it seems like too destructive a function to leave in its current state.
I've used Linux for about 2 years now, but always on KDE until just recently. From this perspective, I was very surprised to find out that a music player would actually move files to the trash! This strikes me as a very bizarre feature, and not intuitive to many users. I only noticed this feature when I couldn't find a song I had played recently, and when I checked the trash it and about ten other songs with the same word I'd used to search on it were in there! Since there isn't a restore from trash option (also surprising to me), I had to figure out where each file belonged. At first I assumed I must have done this via nautilus by accident; it was only a few days later that I realized it was Rythmbox hat had done this. I'm not sure how it happened, but to be honest I had never considered that I might accidentally delete music in a player like this. The relationship between this behavior and the lack of a restore from trash feature has already been mentioned. I would also like to point out that the inability to recursively set an entire folder structure to read only in Nautilus also makes this a worse issue than it otherwise would be. As I understand it, the only workaround is to use chmod -R 544 from the command line for all folders which contain music files. I can see why power users might like using rythmbox to manage their music files, but I think this is a dangerous default setting especially if you have kids! I think the best way to do this for both worlds is to have an option under preferences, with the default setting disabled. Having read through the previous posts, you could even have three radio buttons (allow with no warning, allow but warn me, don't allow). BTW, aside from this rather alarming "feature", I really enjoy rythmbox as a player. Now that I've set all of my music files to read only, I can now enjoy my music without fear of deleting it.
*** Bug 350862 has been marked as a duplicate of this bug. ***
I'd like to raise another point regarding the "Move to trash" feature; regarding the keyboard shortcut. Ctrl-T is also the "New Tab" shortcut for most web browsers, and I occasionaly hit it while Rhythmbox still has focus. It's only a minor inconvnience to move my files back out of the trash, but I too was alarmed the first time I noticed this. I really don't expect that behavior out of my music player.
The problem with this "feature" is that while it is an annoyance as is for some users, it is a REAL problem for others. For example, I use sshfs to access my mount my music directory (which is larger than my local hard drive on my workstation) over the LAN. The move to trash "feature" is easy to accidentally activate (particularly in a multi-monitor setup) where you have a web browser on one screen and music on the other. On a sshfs drive, rhythmbox happily deletes my music whenever I lose track of the focus and hit control T. Permanently. I didn't even know I was losing music until yesterday, and I've destroyed several of my favorite albums. It is a gross violation of user interface principals to EVER do something unrecoverable without asking the user first. Perhaps the real problem is that rhythmbox failed to move the files to the trash. Perhaps the real problem is with sshfs. All I know is that music which I've been painstakingly collecting and organizing for years is gone. I have never posted a bug report for any Gnome project before, but this one was such a betrayal (especially since it is broken as designed, and not an accidental thing) that I considered never using rhythmbox again. Instead, I am posting this in the hopes that the developers will hear the pleas of a pissed off end user and fix the thing so no one else has random holes cut into their favorite albums. This feature is a clone of iTunes' delete music feature. Except that iTunes uses command delete (or control delete on windows), AND give a confirmation dialog box before moving music to the trash. I can't even customize menus such that I can get rid of the stupid shortcut. The feature makes sense in iTunes, because it has an "organize my music for me" feature. If you turn that on, you expect iTunes to start moving files around. Rhythmbox has no such feature. It has no business moving my files around (AND ESPECIALLY DELETING THEM) until it gets one. P.S. I'd like to apologize that this post has turned into something of a flame. However, rather than edit it, I want you developers to see how truly unhappy I am that my software has betrayed me. I know that you are creating this out of the goodness of your hearts, and I appreciate the functionality I have received. However, please, PLEASE fix this so I (and others) don't lose any music in the future.
What version of rhythmbox are you using? The "Ctrl-T" shortcut was removed in 0.9.7 for exactly this reason: 2006-10-30 James Livingston <doclivingston@gmail.com> * shell/rb-shell-clipboard.c: remove the Control-T shortcut from move-to-trash, since there have been reports of people accidently deleting tracks and it probably isn't a common enough operation to be worth a shortcut. I agree, however, that a confirmation dialog should also be added.
I am using 0.9.6 (default version in ubuntu edgy). I can't upgrade without moving to feisty or compiling from source, but I am appeased to know that the keyboard shortcut has been removed in the next version. I support the adding of a confirmation dialog box also, if that is possible.
Please fix this issue! This is incredibly annoying and I just spent the last hour restoring 900+ files to their correct folders. I would have spent much longer, but I had just backed up the files. Still, transferring 14G of data across a 10/100 link is not my idea of fun. I was trying to remove, and I accidentally clicked trash.
I'd say, kill this idea, as people can now restore from the trash in nautilus: http://bugzilla.gnome.org/show_bug.cgi?id=41850#c38
Sorry, i can't agree with Comment #19. It's very annoying that move to trash doesn't ask. even nautilus ask if i want to move something to trash. So i suggest: a.: give the possibility to disable the "move to trash" feature in the preferences. b.: show a dialog like nautilus (yes, yes to all, no, no to all)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/119.