[Enhanc] Trash can

[pascallothar]

Now, when you tidy up your tree and, for that, you delete an item, there is a notification asking you if you are sure to want to do this. But later, you could regret doing it. But it is too late. So I propose to implement a Trash Can.

How to implement it?

I am not a developer, but here are some ideas.

• Create a Folder with the Title "Trash".
• For Multi-ScrapBook, it would be a "Trash" per ScrapBook.
• Make it not deletable.
• Replace the "Delete" entries in the different menus by "Move to Trash".
• Keep the notification feature asking you if you are sure to want to do this.
• This entry would move an item, a bunch of items or a folder to the folder "Trash".
• So the moved item would be at the bottom of the folder "Trash".
• It would be even better if this item would be renamed (the title, not the repertory) by prepending it with the date and hour of deletion.
• This date could be the date already saved in the Scrapbook X "Preferences" or the ISO format for Date and Hour [https://en.wikipedia.org/wiki/ISO_8601].
• Even if two items would have the same Titles, it would not be a problem since they have two different Scrapbook ID.

Emptying the Trash Can:

• Creating a process that would:
• To address the #17 issue,
• Rename each item of the types that have a Scrapbook ID repertory, one by one, by prepending it by (for example) ~ or del, before detaching it from the tree and putting it at the root of the folder "Trash".
• Only if its Scrapbook ID repertory were successfully deleted, delete the item from the root of the folder "Trash".
• If not, it would be deleted at a next call for deletion made by the user.
• Because this failed deleted item is in a location (in the root of the Trash and not at its initial location in a folder or sub-tree) not "understandable" by the user and probably without a prepended date (because it is only a part of a dated sub-tree), the use of the prefix ~ will notify the user that the item was already called for deletion in the past but that the task couldn't be achieved.
• The deletion process can not be frozen by the errors notified on locked resources.
• After having detached all the items having a Scrapbook ID directory (and having deleted all those not locked by an other process), the deletion of the remaining of the tree can be achieved (folders, bookmarks and separators).

  Here is an abstract of what I said:

• Right-click Title of sub-tree in the sidebar,
• then choose "Move to Trash" in the contextual menu.
• When asked if you want to do this, Click "OK".
• Title of sub-tree will be renamed to {2016-07-29T23:59:59,99+02} Title of sub-tree ({2016-07-29T23:59:59} would be enough and is shorter),
• then moved to the folder "Trash".
• When the user want to empty the Trash Can:
• The process will rename Title of item (which is an item of the type having a data directory) to {del} Title of item ,
• then detach {del} Title of item from {2016-07-29T23:59:59,99+02} Title of sub-tree by moving it to the root of the folder "Trash".
• After having successfully deleted the data directory of Title of item , {del} Title of item will be deleted of the tree of the folder "Trash".
•   
• Of course, some items will have temporarily two prefixes. For example, if Title of sub-tree is itself of a type having a data directory, it will be renamed at some stage to {del} {2016-07-29T23:59:59,99+02} Title of sub-tree .

[danny0838]

We did consider this feature. But there are still several technical complexity and difficulty implementing it, especially to keep the original folder hierarchy and an easy UI to recover it.

For now, a similar approach is to export items before delete, by doing this we can easily recover them by importing them back if something really go wrong.

[3dxpoint]

Useless feature imo. What if you regret after deleting from "Trash Can"? Do you want danny to implement "Landfill" too where deleted trash goes?

[pascallothar]

@3dxpoint , IMHO, what is useless is your comment. If it is useless for you, you don't need to use it and let the others use it if they want. If it would be so useless, why is this feature implemented on the usual filesystem?

We don't need to implement a "Landfill" as you mentioned, since we want already send you ( @3dxpoint ) there to do the job :-)

[danny0838]

FYI: this is implemented in the successor, WebScrapBook.