Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CLOSED] Show "Confirm Delete" dialog for files, too #9087

Open
core-ai-bot opened this issue Aug 30, 2021 · 12 comments
Open

[CLOSED] Show "Confirm Delete" dialog for files, too #9087

core-ai-bot opened this issue Aug 30, 2021 · 12 comments

Comments

@core-ai-bot
Copy link
Member

Issue by MarcelGerber
Sunday Dec 21, 2014 at 13:40 GMT
Originally opened as adobe/brackets#10258


For #8651 and #10190


MarcelGerber included the following code: https://github.com/adobe/brackets/pull/10258/commits

@core-ai-bot
Copy link
Member Author

Comment by redmunds
Sunday Dec 21, 2014 at 16:19 GMT


@MarcelGerber It was a conscious decision by Brackets team to not display a confirmation dialog when deleting files (because they can be retrieved from Trash/Recycle Bin). I know that some people would like this, but showing this dialog needs to controlled by a preference which is off by default.

@core-ai-bot
Copy link
Member Author

Comment by MarcelGerber
Sunday Dec 21, 2014 at 19:03 GMT


As I've already pointed out in adobe/brackets#8651 (comment), there are not-too-edgy cases where there's no trash available.
Take a USB stick, for example. On Windows at least, if you delete a file on a removable disk (USB stick, SD card, USB device, ...), there's no way to recover it later on.
We'd have the same with a cloud file system like Dropbox, Google Drive or FTP.

So the best solution would be to not have a prompt shown if trash is available for the current file, and to have it shown in the other case or if the user set a pref. But I don't think we can determine whether trash is available, so imo the best solution is to always show a prompt.

Also, the way we do it right now is a little odd as well, as we show a prompt for folders but not files, even though you can (usually) recover both. Why folders?

And if it matters, what Windows does is this, at least with my configuration:

  • Delete file/folder reversibly (move to trash): Show no prompt
  • Delete file/folder irreversibly: Show a prompt

@core-ai-bot
Copy link
Member Author

Comment by TomMalbran
Tuesday Dec 23, 2014 at 22:17 GMT


I agree with@MarcelGerber that we should always show the prompt by default. If we really need it, we can add a pref for it, but disabled by default.

I know that we discussed this before, but since then, there have been several request to add a prompt, so we should reconsider it. Even if is easy to recover from the trash (when it is possible), it is easier to say "no" if you clicked delete by mistake.

@core-ai-bot
Copy link
Member Author

Comment by redmunds
Tuesday Jan 06, 2015 at 18:18 GMT


What if we add a "Prompt on Delete" (or something like that) menu item to make this setting easy to toggle?

If we have an easy way to turn it off (i.e. not everyone knows how to edit JSON) then I can live with the preference being true by default. How does everyone else feel about that?

I think this would belong in the File menu.

@core-ai-bot
Copy link
Member Author

Comment by MarcelGerber
Tuesday Jan 06, 2015 at 18:30 GMT


My idea would be a "Don't show this again" checkbox in the dialog, but we've never used checkboxes in dialogs before, so I'm not sure if this needs extra work.

But still, I think in cases where there's no trash available, a warning is a must-have.

@core-ai-bot
Copy link
Member Author

Comment by redmunds
Tuesday Jan 06, 2015 at 19:12 GMT


@MarcelGerber The problem with "Don't show again" is people will then need to know how to get back to showing the prompt, so I think we'd still need a menu toggle in that case.

@core-ai-bot
Copy link
Member Author

Comment by peterflynn
Wednesday Jan 07, 2015 at 01:13 GMT


We probably shouldn't make it too easy to turn the dialog off if we can't reliably detect which cases are non-undoable (in that case we'd want to ignore the setting and show the dialog anyway). Until then, IMHO it'd be ok to just have this dialog be always-on with no option to disable.

If the user is doing a lot of delete operations, it's faster to use the OS anyway (since you can multi-select), so I'm not too worried about slowing down the workflow here a tad.

@core-ai-bot
Copy link
Member Author

Comment by ficristo
Wednesday Jul 20, 2016 at 19:15 GMT


Atom, VSCode and Eclipse have the dialog.
Sublime2 does not.
I'd say to add this, and add a preference later if needed like@TomMalbran said.

If people didn't change their system preferences, the deleted file should go to the Recycle Bin: I think the confirmation message should say something about it.

@core-ai-bot
Copy link
Member Author

Comment by MarcelGerber
Friday Jul 22, 2016 at 21:13 GMT


@ficristo I've changed the string, but I'm not to keen on the current wording, either. I feel like "In most cases" is too vague.
Any suggestions?

@core-ai-bot
Copy link
Member Author

Comment by ficristo
Saturday Jul 23, 2016 at 07:49 GMT


Actually CONFIRM_FOLDER_DELETE and CONFIRM_FILE_DELETE should be similar.
While I think it is better to mention the trash-can I guess CONFIRM_FOLDER_DELETE was like that since ever: so just leave the description as it was.
I'm sorry to have caused you some more work...

Restore the description and LGTM.

@core-ai-bot
Copy link
Member Author

Comment by MarcelGerber
Saturday Jul 23, 2016 at 20:25 GMT


I've now decided to unite CONFIRM_FOLDER_DELETE_TITLE and CONFIRM_FILE_DELETE_TITLE to CONFIRM_DELETE_TITLE since they're probably similar in all languages (the difference should be clarified in the dialog body, not in its title).

Also reverted the string change.
Please have another look.

@core-ai-bot
Copy link
Member Author

Comment by ficristo
Sunday Jul 24, 2016 at 07:20 GMT


Thank you, LGTM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant