On 12 Feb 2019, at 10:37, Eike Ziller <eike.zil...@qt.io<mailto:eike.zil...@qt.io>> wrote: On Feb 12, 2019, at 09:54, Volker Hilsheimer <volker.hilshei...@qt.io<mailto:volker.hilshei...@qt.io>> wrote: On 11 Feb 2019, at 19:16, Jason H <jh...@gmx.com<mailto:jh...@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). Context being whether a “moveToTrash” API without a comprehensive trash-can-management API (which gives access to the contents, the ability to empty the trash, and the ability to restore arbitrary content from the trash-can) is a good idea. The moveToTrash API as suggested in https://bugreports.qt.io/browse/QTBUG-47703 returns the location of the file in the trash-can after the move, so the application can store that information and give the option to restore those files/directories that were trashed through the application. Cheers, Volker
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
