Doesn't XDS fill the need here? 

There's a short discussion from:

http://mail.gnome.org/archives/gtk-devel-list/2005-November/msg00017.html

As much as I can figure out the patch from a quick glance, I don't like
it much. It looks like extra gunk added all over the DND system, including
pushing even more X-specific logic into the GTK+ layer.

Ed?

I tend to agree with Owen here; we should look into implementing XDS support
before kludging further extension onto the XDND spec.

re comment 1, comment 3:

XDS is not a solution. The XDS conversation takes place *during* the drop stage of the DND process (before XdndFinished), so using XDS will tie up the X server just as bad as basic Xdnd.

The problem is that Xdnd is inherently non-parallel; because it uses a named selection, only one drag process can be ongoing at any one time. This conflicts with intuitive usage of file-roller, where one would expect to be able to drag a file from file-roller to nautilus, then while that first file is still being unpacked drag another file somewhere else. 

This is why a protocol extension is needed.

I know XDT isn't perfect, and the patch is I admit pretty damn awful. That's why I slammed it out; to get an implementation out there for testing and comments.

The idea of using XDS is that file roller is told where to extract the
files and extracts them after the drag ends. That should fix the normal
case of dragging into nautilus fine.

Owen: It doesn't because XDS just allows to negotiate single-file drops while we clearly want a protocol that allows to drag multiple files at once.

I'm pretty sure that the path transferred in the XDS spec is the folder
to save the files in, not the full path for a single filename.

(How would the target know the full path? The user just dragged over
a folder window and released)

I'm referring to http://www.newplanetsoftware.com/xds/

> I'm pretty sure that the path transferred in the XDS spec is the folder to save the files in, not the full path for a single filename.

Indeed, the drop target exposes the folders to save the file in.

> (How would the target know the full path? The user just dragged over
a folder window and released)

Converting step 1...4 into a purely semantic description, the target then retrieves the file name of the file to be dropped, converts it into an URI (e.g. name -> file://host/path/name), and passes it back to the drag source. In Nautilus, conflict handling would happen at this stage. Then, the drag source will try to save it itself at the specified location and may fail, still allowing the drag source to pass "application/octet-stream" data around, which will then be saved by the drag target application to the specified location.

The relevant point is that the conflict handling can only done for ONE file, so you cannot drag multiple files at once with conflict handling, which renders this protocol (version 0) quite useless for serious tasks. Me and another interested developer tried to contact the author of the XDS spec but he wasn't to fond of extending the protocol for multiple files, and proposed to do the conlict handling in the drag source.

Doing it in the drag source sounds like the correct behavior to me.

I don't like the idea of having file-related conflict dialogs in all drag source applications, which includes about every GTK+ office software available. Do we need a library for this, or can we provide a simple GTK+ wrapper API [using GtkFileSystem?]?

File Roller:
 - Is a source of multiple files
 - The files have to be unpacked by an potentially expensive extraction
   software
 - Should display progress dialog when unpacking
 
"Every GTK+ office software"
 - None of those

I don't think office applications are normally sources of drag information
at all, unless you are using XDS from the file dialog (something we don't
normally do in GNOME, though RoX does.) 

For XDS from the file dialog, it doesn't seem like a huge pain to do 
simple conflict handling in the source ... 
"The file Foo.doc already exists" and pop them back to the file 
dialog to pick a new name should be OK.

(In reply to comment #5)
> The idea of using XDS is that file roller is told where to extract the
> files and extracts them after the drag ends. That should fix the normal
> case of dragging into nautilus fine.

OK, so (following http://www.newplanetsoftware.com/xds/):

0.
   i) Source creates window property XdndDirectSave on itself, type text/plain, content - ""? "."?
   ii) Source specifies action XdndDirectSave
   iii) Target receives XdndPosition over a folder icon or in a folder window
1.
   i) Target receives XdndDrop
   ii) Target retrieves data from XdndDirectSave property, writes back full uri (which is just the folder path) in XdndDirectSave property, requests XdndDirectSave
2.
   i) Source receives XdndDirectSave, retrieves uri from XdndDirectSave property
   ii) Source checks uri is accessible and writable folder (by gnome-vfs)
      a. Source checks for conflicts on the multiple files it wants to save? Or will it just silently rename them ("file" -> "file (1)" etc.)?
   iii) If folder is OK, source sends "S"; else it sends "E".
3.
   i) Target receives result; sends XdndFinished. It refreshes its display to show the "new file", but there's nothing there yet.
4.
   i) Source receives XdndFinished
   ii) Source deletes XdndDirectSave property
   iii) Source ungrabs pointer.
   iv) If folder was OK, source begins saving files:
      a. silently renaming duplicates?
      b. putting up a dialog to ask what to do with duplicates?
   v) If folder was not OK, source notifies the user - in a dialog box? in status bar?

Seems there's three points where we abuse Xdnd:
a) setting "" as XdndDirectSave property
b) not actually saving anything before sending "S"
c) not falling back to application/octet-stream (sending "F")

This is all on the source side, as long as the target does the obvious thing when confronted with an empty string for XdndDirectSave property. It might fall apart when faced with a less accommodating file manager. (And what if the target supports a different set of URI schemes?) That said, file-roller/nautilus should be fine, because we control both ends.

We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.