-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement deletion using trashItemAtURL #24
Comments
Following up on #14 (comment) ... I implemented this on the @JakeChampion I'm wondering what I did differently; could you test this? If the Put Back option turns out to work in all cases when using the |
@ArturKovacs It looks to not have "Put Back" option for me: I used the v2-dev branch and ran My computer stup is:
|
The thing about this is that using a trashing method that doesn't allow to "Put Back", just seems to defeat the whole purpose of using the trash instead of deleting the file permanently. But we are not the only ones who suffer from this behavior; this seems to be a bug in macOS. See: sindresorhus/macos-trash#4 It's actually somewhat funny how bad the trashing APIs are on macOS. It's not that they are badly designed, because they are pretty clean, to be fair. However it's not only a lot more limited than what you can do on Windows and Linux but even what's available is broken. And has been broken for 6 years now. |
I'm currently considering simply not supporting the What are your thoughts on this @JakeChampion and @disconsented? |
I'm with you on that decision, it is impressive how this macOS bug has been around 6 years and not fixed |
We decided to implement it to avoid that one single scary pop-up, however, I don't think the loss of put back makes sense in this context. It'd be a nice option, but I don't think many folks would mind if it wasn't implemented. |
How so? Let me clarify my perspective, so that you can point out what I'm missing: I believe that the purpose of the Trash is to be able to change one's mind after deleting something and restore/put back items to their original location. However if restoring is not possible then putting items into the Trash is the same as permanently deleting them. Using the AppleScript+Finder method produces a dialogue asking for additional permissions. Using the NSFileManager method prevents "Put Back". Therefore if the additional permission dialogue needs to be avoided, then the program should either not move items to the Trash at all (because that cheats the user, as they won't be able to "Put Back"), or the program should remove the file permanently with for example Supporting the |
They can be restored by the user moving the files out of the trash and placing them somewhere on their machine. Which is different to permanently deleting the files but not as user friendly as having a "put back" option which restores the file to it's original location in the storage system. |
Oh, I did not realize that. I'm a noob at using macOS. Alright, in that case I'll leave this option available, but keep the Finder method as the default. Thanks a lot for the input from both of you, it was very helpful! |
Yep, the only other thing that is different is the lack of the put back option in finder. I'd looked into this, and supposedly we'd need to manipulate |
I think that macOS users will be rather accustomed to permission request dialogs by this point. It's probably better to live with that, than to sacrifice the "Put Back" option (though I agree with the earlier comment that avoiding permanent deletion is a significant benefit in itself). Just my two cents as a happy user of this library. |
Thanks for your thoughts @theodore-s-beers, it seems that keeping the Finder method as default was a good choice. On that note, version 2 is released now. |
Closing this as it was implemented in #11 |
Currently on the main branch we are deleting by using an AppleScript telling Finder to delete items. However there are native Objective-C APIs that allow doing this for example
trashItemAtURL
.The text was updated successfully, but these errors were encountered: