[Development] New API design for file system operations

[Eike Ziller]

> On Feb 12, 2019, at 09:54, Volker Hilsheimer <volker.hilsheimer at qt.io> wrote:
> 
> 
> 
>> 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.

The context of the top statement here seems to have gotten lost, but
“restoring data from the trash” would in the best case be part of the undo stack of the application which you used to trash it, so I’d argue that “restoring data from the trash” is an operation that an application would like to have access to (at least for the file that it trashed before).

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.ziller at qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B