Dolphin: Move option shouldn't be given when dragging read-only files.

[David Faure]

On Tuesday 20 November 2007, Leo Savernik wrote:
> Am Montag, 19. November 2007 schrieb Lexual:
> > The user should *NOT* be given the option to move a read-only file.
> > It is impossible to do this.
> 
> Wrong wording. Read-only files can be moved if their containing directory is 
> writable. The error only occurs if the containing *directory* is read-only.

Yep, KonqOperations::doDropFileCopy has code for this already (in the case of local files).
But I think Dolphin doesn't use KonqOperations for this. Peter, any reason for not using KonqOperations::doDrop()?

> > Trying to do this gives the error message:
> > Unable to delete <foo.file>
> >
> > This appears to be a long standing bug which hasn't received any attention.
> >
> > http://bugs.kde.org/show_bug.cgi?id=133235
Well that bug is about "remote" files like system:/ ... 

The problem is, that we don't have the full KFileItem in the drop method, we only have urls in the dnd mimedata...
and even if we had the KFileItems we would need to check the parent item, in fact, not the item itself.

So we would have to use a KIO::stat() to figure out if the parent dir is writable -- that would be slow.

Alternatively, we should ship this information into the mimedata since the drag side has this information already
(when dragging from dolphin/konqueror, not in other cases of course).
Hmm. Sounds like a job for KonqMimeData (adding "application/x-parent-dir-writable" -- set to false if the parent dir of any item is not writable, 
and dolphin's draganddrophelper.cpp should use KonqMimeData anyway (for dnd of most-local-urls)
I guess we can clean up the application/x-qiconlist stuff from it, if dnd of multiple icons works already in dolphin...

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).