renchi at pooh.tam.uiuc.edu
Tue May 24 21:04:52 BST 2005
On Tue, 24 May 2005, David Faure wrote:
> Wrong list for feature requests, but maybe you want to implement the following? :)
this was a disguised attempt to get you to tell me a good solution to a
problem we are having :).
> I would say it's up to the caller (are you talking about konqueror?) to use
> KFileItem::mostLocalURL or KIO::NetAccess::mostLocalURL to transform media:/foo
> and system:/bar into local paths before calling kio_trash. Not all "class local" kioslaves
> can have their URLs resolved to local paths, IIRC, so this can only be done
> for those where mostLocalURL works.
i wasn't talking about konqueror. we make extensive use of kioslaves in
digiKam (to ensure that the metadata attached to a file doesn't get lost
when you use kio::job to copy/move files around). The only case where it
doesn't work well is trashing. We are currently doing what you suggested,
converting the vfs url to a file url and then calling kio::trash. But when
a item is trashed and user restores it, there is no way to restore back
its metadata as well. I was thinking something on the lines of being able
to pump some metadata to the trash kioslave using KIO::metadata,
which gets stored along with the Trash Info. And when the item gets
restored, retrieve the metadata as well. But for this the trash kioslave
has to handle put/get as well (which it doesn't do currently).
I can see other possible uses of it as well, for eg, a ipod kioslave could
add a metadata, saying it belongs to this particular ipod, and when the
restore function is called on a trashed file, it could prompt the user to
connect the ipod.
More information about the kde-core-devel