"Remove torrent" action in GTK GUI is error prone and should be split in two

[nixar]

One of the most common action in the UI is removing completed torrents.

In the current state (FTR I'm looking at 1.3.1), the same UI is used to address two very different user intentions:

1. After a torrent is completely downloaded, stop deluge from dealing with it (seeding) but keep the data around.

2. Whether the torrent is entirely downloaded or not, stop dealing with it AND remove the data.

The current UI is inappropriate for several reasons, and I speak from both a theoretical UX point of view and practical use:

- The user already knows whether he wants the data deleted or not before he selects "Remove torrent," yet we have to interrupt them with a modal dialog box.

- It's _extremely_ easy to delete data by mistake when that was not their intention, they just need to misclick by a few pixels, and there is no warning (note: warnings are not the solution anyway).

- There is usually no reason to keep the data around when a torrent is not 100% downloaded. They can just pause if that's what they want. In the extremely unlikely event (1 in a million uses?) they want to keep the incomplete data but outside of Deluge, they can always go to the temp folder and copy it. No need to confuse the user, however slightly, in the 99.999% of cases.

- It pops up a modal dialog box. Modes are evil.

Proposed alternative solutions:

A. Separate "Remove torrent" and "Delete files" actions in the menu. Since the former is both less destructive and more common than the latter, bind it to the "Backspace" AND "Del" key. No confirmation dialog for "remove" required since no data is lost you can easily reopen the torrent file. Confirmation dialog could be considered for "delete files," but it would be much better IMO to move the files to the desktop environment's trash without confirmation, since this is reversable.

B. Only offer "Delete files," bound to DEL/BS when torrent is not complete; files are moved to trash (hence user undoable). It changes to "Remove torrent" (does not delete files) when torrent is complete, same keybinding. Optionally offer "Delete files" in the latter case, but not as bound to DEL/BS in that case.

[nixar]

state diagram for solution B

[s0undt3ch]

You do have a point, yet, I still like the ability to delete(data included) completed torrents(Ie, it was not what I was after), so, both options should be shown, ie don't base them on torrent state.

About key bindings, DEL, delete torrent, keep data around. SHIFT-DEL delete torrent, data included.

Different behaviours based on torrent state for the same keybind, this I dislike.

Just my one cent, lemme known what's decided and I might take up the ticket, though, if anyone else want's to pickup the ticket, go ahead.

[nixar]

Well this proposed solution is based on the following principles:

- Reduce the cognitive load for the user: don't overwhelm with options, don't require the user to have to think too much when doing something common

- Don't surprise the user: no dialogs when they can be done away with, actions should always be reversible

Keybindings that change meaning may be slightly unusual (however DEL/BS already do mean something different when either in a list or in a textbox), but they are better UI wrt the stated principles than the alternative.

[James_Kern]

Attached a couple screenshots for how I propose this is addressed. Basically move the "Remove with data" button to a checkbox, which when selected shows a little warning. I don't want to really change to workflow, but I would like to minimize the risk of someone accidentally deleting files due to misclicking by a few pixels.

[James_Kern]

Attached a patch implementing the changes I described.

[HolgiH]

Speaking as happy Deluge user: this looks like a great idea! +1 :-)