[Development] New API design for file system operations

[Volker Hilsheimer]

> On 11 Feb 2019, at 19:16, Jason H <jhihn at gmx.com> wrote:
> 
> 
>> The question for me is: why would an application (that is not a file explorer) want to do any of this? I honestly don’t see the use case.
> 
> When I filed the bug against KIO not having a "trash" feature it was because I was working in digikam (photo library) in KDE - this is MANY years ago (2004,  https://bugs.kde.org/show_bug.cgi?id=88615 ). Anyway, I deleted the library in the application, and ALL my photos went *poof*. I looked in the trash... Nothing. I expected my user-generated data to to be recoverable in the trash. 
> 
> So the use case, is when the user has generated data that the application does not own, where it should not assume ownership of said data and the user has requested it be removed. 
> OR 
> The user has requested the data be removed but not destroyed, so in a way that the data can be potentially recovered. 

But that’s a usecase for a “move-stuff-to-the-trash” function, right? As in “remove those files, but do not delete them permanently”.

The user would expect to be able to see what’s in the trash, and to restore stuff from there, using the standard desktop trash-can metaphore, not some application specific shenanigans.

You would want the application perhaps to be aware of the user restoring data from the trash, ie adding the files back into the workspace, or the photos back into the library. In that sense, "restoring from trash" is just the same as “restoring from backup” or “downloading from the internet”, I suppose.

Cheers,
Volker