From: Bill Kendrick <nbs@so...> - 2011-04-18 18:44:53
In the last couple of days, I implemented very basic support for the
freedesktop.org trash specification (as best I could understand it).
Basically, before, Tux Paint would simply call "unlink()" to delete a file.
Now, it does this:
* If there's an $XDG_HOME_DATA folder, assume Trash is in there,
else assume it's in $HOME/.local/share
* It determines the name that should be used for the Trash'd file;
if another with the same name exists, it adds "_1" to the filename;
repeat until it gets up to _100, and then it gives up and unlink()'s.
* It tries to move (via 'rename()') the file from the user's Tux Paint
directory and into the Trash's "files" directory.
* If that fails, e.g., due to the Tux Paint save dir and the Trash being
on different filesystems, it copies the file (via fopen/fread/fwrite).
It then unlink()'s the original file.
* It creates a metadata file in the Trash's "info" directory that lets
the Trash can know when the file was deleted, and where to restore it
(including original name).
* Finally, it calls KDE's "dbus-send" (via a system() call) to tell
any KDE listeners (e.g., a Trash icon on one's panel or desktop) that
files were added to the 'trash:/' URL. This causes an empty trash icon
to change to not-empty.
* Make sure trash icons in other freedesktop.org-compatible environments
(e.g., GNOME; also xcfe? others?) also get updated, somehow.
* Figure out how to do this in Windows (95 thru 7, if possible!)
* Figure out how to do this on Mac OS X
* Figure out how to do this on Haiku
* Expose and document 'UNLINK_ONLY' #define that can be used to revert
Tux Paint back to the unlink() method (rather than only unlink()'ing
if all else fails), which may be useful for some platforms (mobile?)
Sent from my computer