Review Request 120573: [OS X] make KDE's trash use the OS X trash

[René J.V. Bertin]

> On Oct. 14, 2014, 9:35 p.m., Thomas Lübking wrote:
> > kioslave/trash/kcmtrash.cpp, line 220
> > <https://git.reviewboard.kde.org/r/120573/diff/6/?file=318518#file318518line220>
> >
> >     don't know about the "exotic OS" policy on this, but changes to i18n strings need to happen for new minors only (unless you get an exception), ie. for 4.15

Would it be "better" if I made this a regular string, with something like a // TODO: internationalise ?


> On Oct. 14, 2014, 9:35 p.m., Thomas Lübking wrote:
> > kioslave/trash/trashimpl.cpp, line 816
> > <https://git.reviewboard.kde.org/r/120573/diff/6/?file=318520#file318520line816>
> >
> >     I don't understand why this cleanup is required on osx, but not other systems?

On other systems, there's only a single trash at a time, and it's rendered to the user via kde-runtime. 
Here we're putting that KDE wastebin inside another one - think of it as an ashtray inside a larger garbage can. KDE only knows the ashtray, but OS X sees the whole garbage ... so in order to play nice KDE has to get rid of the ashtray too, each time it empties it.

I noticed that there's a win32 backend which seems to use a native API interfaced to TrashImpl. I presume that something similar could be done on OS X (haven't checked) and it's almost certain that I could replace the `files + info` infrastructure by something that uses extended file attributes (resource forks no longer exist...) but TBH I'd rather use the simpler route implemented here. Besides, suppose a user does go into the Finder's Trash to restore a binned file, any "trash info" stored as a file attribute will remain attached, which isn't very proper.


- René J.V.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120573/#review68412
-----------------------------------------------------------


On Oct. 14, 2014, 1:59 p.m., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120573/
> -----------------------------------------------------------
> 
> (Updated Oct. 14, 2014, 1:59 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Runtime and David Faure.
> 
> 
> Repository: kde-runtime
> 
> 
> Description
> -------
> 
> KDE on OS X does not handle the desktop session (no "Plasma") nor can it rely on XDG to obtain the proper paths to use for something like the trash. As a result, all applications that propose to move things they manage to the wastebin (Dolphin, but also digiKam) will store those items in a place that has no particular meaning on OS X, and that will thus tend to fill up.
> 
> OS X stores trash in one of several locations. Files trashed from the boot volume (and/or the volume containing $HOME, I don't actually know that) end up in `~/.Trash`. Files deleted from other volumes end up in `/Volumes/volName/.Trashes/uid`, where volName is the volume name (regardless whether it's an external or a remote drive; only mounted NFS shares are handled differently) and uid the numerical user id. Permissions on `.Trashes` are the same as those expected by KDE.
> 
> The kio_trash kioslave appears to support several actual trash directory locations, just like OS X. `TrashImpl::init()` creates a standard trash in `~/.local/share/Trash` (at least under OS X) but also `TrashImpl::trashForMountPoint()` that is used in cases I have not yet encountered.
> 
> On OS X, my modified `TrashImpl::init()` sets the standard trash directory to `~/.Trash/KDE.trash` and will create the `files` and `info` subdirectories as required, because they will of course be deleted when the user empties the OS X trash. `TrashImpl::fileRemoved()` has been modified to call a new function, `deleteEmptyTrashInfraStructure` to delete the KDE trash's internal infrastructure when the wastebin is empty so that OS X also sees the trash as emptied. (Since implementing `deleteEmptyTrashInfraStructure` this feature actually works, as expected as far as I can tell).
> 
> Remains to be done:
> - determine in what cases `trashForMountPoint()` is used, and finish the modifications for it to use `/.Trashes/uid/KDE.trash`
> 
> 
> Diffs
> -----
> 
>   kioslave/trash/kcmtrash.cpp f4811fd 
>   kioslave/trash/trashimpl.h bc68723 
>   kioslave/trash/trashimpl.cpp 30ee05b 
> 
> Diff: https://git.reviewboard.kde.org/r/120573/diff/
> 
> 
> Testing
> -------
> 
> On OS X 10.6.8 with kdelibs and kde-runtime git/4.14, using Dolphin. Tested actions are
> - move items to wastebin from $HOME and a directory on a different volume
> - restore items to both places
> - empty wastebin through Dolphin
> - empty OS X trashcan
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20141014/d730fabc/attachment.htm>