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 545937 - 'Delete from drive' should be changed to 'Move to Trash' (Recycle Bin)
'Delete from drive' should be changed to 'Move to Trash' (Recycle Bin)
Status: RESOLVED WONTFIX
Product: banshee
Classification: Other
Component: general
git master
Other Linux
: Normal enhancement
: 1.x
Assigned To: Banshee Maintainers
Banshee Maintainers
gnome[unmaintained]
: 560067 571365 (view as bug list)
Depends on: 603834
Blocks: 648337
 
 
Reported: 2008-08-02 02:05 UTC by Matt Drake
Modified: 2020-03-17 08:27 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Matt Drake 2008-08-02 02:05:53 UTC
Instead of permanently deleting a song from a user's drive in Banshee's context and Edit menus, songs should be moved to the Trash. This makes deleting songs safer and lets the user restore songs in the event that a mistake was made.
Comment 1 Gabriel Burt 2008-11-09 21:02:49 UTC
*** Bug 560067 has been marked as a duplicate of this bug. ***
Comment 2 Gabriel Burt 2009-02-12 00:57:55 UTC
*** Bug 571365 has been marked as a duplicate of this bug. ***
Comment 3 Michael Ivanic 2009-07-21 06:20:53 UTC
I've been looking at this bug and found the relevant functionality (to move files into the recycle bin) within the gio-sharp library. I need to of course test this on windows to see if this works there as well, and change the dialog prompt.

So on my local copy (which is up-to-date) I've done 'add reference'/gio-sharp within monodevelop. Then I have put the following method into the Banshee.IO.Utilities class:
public static class Utilities
{
    public static void MoveToRecycleBin(SafeUri uri)
    {
        GLib.File file = GLib.FileFactory.NewForPath(uri.AbsolutePath);
        file.Trash( ... );
    }
    .
    .
    .
}

And my intention is to call this from Banshee.Library.LibrarySource, I don't think that the trash can is relevant for removable devices ?

However my problem now, is that even though Monodevelop CAN see the 'File' interface within 'GLib' I get the following compilation error ...

"The type or namespace name `File' does not exist in the namespace `GLib'."

This is my first attempt at resolving a Banshee issue, I apologise in advance if my question is a bit nooby or if I've missed something obvious ...

I'm running Ubuntu 9.04, and have installed the relevant libraries straight out of the vanilla repositories for Jaunty. gio-sharp does tell me its 'unstable' however and has a version number 0.0.0.0.
Comment 4 Andrés G. Aragoneses (IRC: knocte) 2009-07-21 09:04:41 UTC
(In reply to comment #3)
> I don't
> think that the trash can is relevant for removable devices ?

It makes sense, at leaste I've seen a trash folder sometimes when browsing them (different for each user, for example: .trash-mike, .trash-joan, ...).

> However my problem now, is that even though Monodevelop CAN see the 'File'
> interface within 'GLib' I get the following compilation error ...
> 
> "The type or namespace name `File' does not exist in the namespace `GLib'."
> 
> This is my first attempt at resolving a Banshee issue, I apologise in advance
> if my question is a bit nooby or if I've missed something obvious ...

I guess you should add the reference to the makefiles as well. And to the configure script if it's not already added.
Comment 5 Gabriel Burt 2009-12-05 04:26:37 UTC
Doing this depends on having a GIO IO backend.  We have one that mostly work, but with one big bug - it can't write metadata back to files using taglib#.  See bug #603834.  I'm going to mark this as being blocked by that.

The work to add File.Trash and Directory.Trash method to Banshee.IO could be done now, though, if somebody is up for it.  See src/Backends/Banshee.Gio/
Comment 6 Josh Biggs 2010-02-19 13:30:19 UTC
May I suggest that in the interim, until this blocking issue is resolved, that at a minimum a confirmation warning is placed in the UI describing to the user the action. Something to the effect of . . . "Confirm Delete. This action will remove the file from your local storage. You will not be able to recover this file once deleted."

Also, I've recently opened another bug ticket for this issue, you can review and close as duplicate if needed. (Bug 610452)

Thanks!
Comment 7 Bruce Pieterse 2010-12-01 22:05:17 UTC
Banshee 1.8.0 had an interesting and probably amazing file deletion process. When you deleted a song, it wasn't deleted immediately compared to 1.9.0. This allowed the user to enjoy the rest of the song before it automagically deleted the song at the end of playback. One downfall of this was that performance after deleting the song and hitting next, caused Banshee to sometimes lock up between 3 to 15 seconds.

I currently have Banshee 1.9.0 (1.9.0+git20101130.r1.f01dd3a-0ubuntu1+maverick) installed. When a song has been deleted, playback will stop. I did notice that there is a short application lock up if you enqueue one song and delete the current song that is playing. In some cases Banshee doesn't play the enqueued track at all.

Quite simply put can the following be achieved to fix the above:
- If a song is deleted, can it be moved to a Trash folder/playlist
- Users have an option to set the Trash folder/playlist to be emptied when closing banshee in preferences
- The ability to enable/disable "Play next song after deleting" in preferences if "Move songs to Trash" is enabled.

Benefits
- If the Trash playlist is introduced, users can use the 1.8.0 feature of the file deletion process which occurs at the end of the song and not immediately. If they do want songs to be deleted immediately, then they can disable this option in preferences "Move songs to Trash".

- If the Trash playlist is included in Banshee, the file does not need to move to the corresponding OS Trash/Recycle Bin.

Thanks :)
Comment 8 Gabriel Burt 2010-12-02 16:22:03 UTC
Bruce, the stop-playing-on-delete behavior is tracked on bug #635544.

I don't think adding a preference to clear-trash-on-quit is a good idea based on simplicity grounds.
Comment 9 Andrés G. Aragoneses (IRC: knocte) 2011-03-01 13:52:09 UTC
*** Bug 643547 has been marked as a duplicate of this bug. ***
Comment 10 André Klapper 2020-03-17 08:27:47 UTC
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Please feel free to reopen this ticket (or rather transfer the project
to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the
responsibility for active development again.
See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.