trash: don't fallback to home trash if trash is unavailable

After my first merge request !2044 (merged), there was another bug report mentioned, which was similar to mine. While the previous merge request would improve the circumstances, it wouldn't solve the issue completely.

So, I drafted this. Strings and comments are not final. I'm mainly requesting feedback, whether this is the correct approach.

My thoughts so far:

  • Users wouldn't expect that files are moved from a removable disk, network share, other partition, ... to the partition containing the home folder, if trashing fails. Well, I didn't expect it, which is why I am here. They wouldn't expect it because it can be slow, it can reduce the life of SSD’s due to the extra useless write-cycles, and other OSes don't do it either.
  • The trash-spec says that "[The implementation] MUST NOT erase the file without user confirmation", if trashing has failed. I interpret it so that the confirmation must be forced, no matter the user-setting whether to ask before deleting.
    • We could also hide the option to move to trash in the context menu and instead only show "Delete" but I think this might be less clear. If the user only sees the "Delete" option but wants to "Move to Trash", they wouldn't know that there is an issue preventing this. Also, it could be overlooked by users who are expecting the text to say "Move to Trash".
  • By returning -1 in TrashImpl::findTrashDirectory, the function TrashImpl::trashSpaceInfo will now return false sometimes, which was an impossible return value before (despite being a boolean). Dolphin does seem to call this function sometimes and handles it, as it should (because it’s one of two values, heck), but still it is some change.
  • Accessing m_trashDirectories directly in TrashImpl::trashForMountPoint feels scary, even though there should be nothing to worry about.
  • The user would expect trashing to generally work, though, and I have a feeling that I have accidentally excluded a lot of cases for trashing to stop working and instead show the dialog. Users shouldn't be annoyed — stuff should mostly "just work", unless it definitely shouldn’t. (Also according to KDE HIG)

Am I on the right track with this? Do you think this issue should be solved? 😄

BUG:502315

BUG:481532

BUG:475235

Edited by Oliver Schramm

Merge request reports

Loading