Not to forget this one:

  http://freedesktop.org/wiki/Draganddropwarts

Currently (GNOME 2.10) when a link or image is dragged from epiphany to
nautilus, a dialog pops up *below* epiphany asking to link or download. In the
download-case, nautilus downloads the image again, instead of using the cache.

The obvious thing to do would be to download the dragged object, and only link
when modkey+drag is used. XDS support may be the key to this.

This would be great to have, really. Would be cool if somebody with X protocol
knowledge could tackle this issue. I remember an attempt which mainly consisted
of scratching my head and looking at rox sources.

The protocol is actually rather straight-forward and you won't need any XLib
calls, the GDK property and selection APIs should be sufficient.

Hrm let's assume I get clipboard data with info set to
gdk_atom_intern (XdndActionDirectSave)

how do I proceed? Will I have to poke around with 'F', 'S', 'E' etc.?

First you would ask the application to save the file, later you would have to
deal with the 'F', 'S' or 'E' response. Christian, did you actually read the
spec at http://www.newplanetsoftware.com/xds/ ? What exactly is not clear about it?

Yes I've read it but things like XA_STRING and hexadecimal numbers scare me
away, because I have neither any knowledge of Xdnd nor of X11 internals. Let's
see whether my to-be-written implementation will scare away *you* ;).

Created attachment 49361 [details] [review]
Proposed (prelimitary) patch against HEAD

Turns out that the biggest hurdle was not the protocol but Nautilus' *foobar*
(censored) DND organization. Please try out whether the attached patch works
correctly - I think it is still buggy when the XDS request fails, i.e. it
somehow doesn't correctly request "application/octet-stream".

Created attachment 49362 [details]
nautilus-xds-dnd.c

Created attachment 49363 [details]
nautilus-xds-dnd.h

I just noted that the two "cb" callbacks are not connected. Maybe we should
reveal the icons there if successfull.

How will that work when the application and nautilus are on the samne DISPLAY
but not on the same machine ? Will the file be piped through X, or will there be
an attempt at saving it at the wrong place ?

Ideally the file://... URL should include the name of the computer the file
should be saved to so the danger of saving to the wrong machine can be avoided.
As to transferring through X, nautilus has the option of re-writing the URL if
hostnames don't match to become a network oriented URL, transferring through X
or claiming it is impossible.

Rich: How can file:// be ambiguous? There is only one "/" directory, due to the
nature of a hierarchical file system. How is the remote connection supposed to
be established?

Xavier: I think an attempt for saving it on the wrong place will be made, since
the directory hierarchy of both machines is different - at least with the
current code. Even if the piping worked, what mechanism would ensure that the
target file is fopened? You're describing an interested problem, although the
user base that will experience this is probably really small for the moment, right?

In my own little personal case, I use remote X apps daily and am sometimes
bitten by these problem. I know few people do that, seeing as GTK+ apps are
unoptimised for network acces (big latency problems) but that's another matter.

IMHO, DnD in general should work much like copy/paste, i.e. be totally network
transparent and pass content instead of reference (file data forward instead of
URLs backward). Or maybe optimize the local case by passing URLs backward
(current XDS behavior) and pass file data forward only in the remote case.

There are so many ways to have a remote X connexion, using the X transport
itself is the only reliable mechanism to transfer data between clients.

Xavier: I think it will work as expected:
- app tries to safe itself, fails because the hierarchy is not identical
- app transfers the document data, and Nautilus safes it to the desired
location, i.e. on the other machine

I think the app should have another mean of discovering that the "other app"
isn't from the same machine, otherwise it will e.g. save on the wrong /tmp.
Otherwise it seems fine.

I've filed bug 321211, which deals with implementing XDS at GTK+ level.

Note that bug 319969, which deals with panel/nautilus launcher dragging could
also be fixed by using the XDS protocol.

Regarding comment #16 and comment #17: both protocols (XDS and XDND) require
the file:// URI to contain a host name.  See this reference:
  http://www.newplanetsoftware.com/xdnd/dragging_files.html
If the application would have to rely on different directory hierarchies to do
the right thing, then a lot of problems could occur.  Not only with /tmp, but
also with other directories sharing similar names.  As I am typing this, I
have on my display some local windows and remote windows from three different
machines.  Two of these machines have access to the same files as my local
machine (NFS mounts), while a third one (accessed via X over ssh) does not
have access to my local filesystem.  However, it also has a /home/ directory
with the same username, and several sub-directories of both home directories
have the same names.  If I would drag a file from the GIMP (used remotely) to
Nautilus (local) and the applications were stupid enough to only look at the
path without looking at the host name, then the file would be saved in the
wrong place.  The XDS protocol should always exchange URIs including host
names, as discussed in: http://freedesktop.org/wiki/Draganddropwarts

Raphaël: the missing host name in the URI is bug 44725.

If I get the comment right, Ubuntu Launchpad Bug #13199 (the infamous file roller bug) depends now on this. See https://launchpad.net/distros/ubuntu/+source/file-roller/+bug/13199 for further reference.

(In reply to comment #22)
> If I get the comment right, Ubuntu Launchpad Bug #13199 (the infamous file
> roller bug) depends now on this. See
> https://launchpad.net/distros/ubuntu/+source/file-roller/+bug/13199 for further
> reference.
> 

The first link was auto-generated and is wrong of course. The second links takes you to the relevant launchpad bug.

The relevant file-roller bug which depends on this bug is http://bugzilla.gnome.org/show_bug.cgi?id=102501 BTW. And sorry for the spam.

hmmm, as file-roller now fully "relies" on this for extraction, and most folks have been used to drag and drop extraction, is there any chance Nautilus could implement this for 2.18? If not, I fear some users out there will be... "surprised" to see the feature vanish, and this bug report might be flooded with duplicates :)

Not to mention the fact that file-roller also has a bug that prevents it from extracting files using the 'extract' button.

So currently, a default gnome-install wouldn't be able to extract files using a desktop tool. 

Not to add pressure ;-)

Well it was broken then (for years now). It is even more broken now (at least it seems so). Perhaps it would be wise to switch to another archive manager for GNOME. Are there any sane alternatives that make use of the Gimp toolkit?

What about Archive? It's from the ROX project:

http://rox.sourceforge.net/desktop/Archive

It has a very simple interface:

1. Drag a directory to it, and then drag the compressed archive out.
or
2. Drag a compressed archive to it, and then drag the uncompressed directory out.

Supports tgz, tar.bz2, tar.Z, rar, ace, tar, rpm, cpio, deb, zip, jar and war archives, plus .bz2, .uu2, .gz, and .Z compressed streams.

It supports the freedesktop.org drag-and-drop specs, so it works fine with Thunar (from Xfce) and ROX-Filer (from ROX).

(unfortunately, it doesn't currently work with Nautilus, because Nautilus doesn't support XDS, the Direct Save protocol)

So all in all it comes back to Nautilus not implementing a decent DnD interface and no XDS? Did nothing ever come of the patches submitted back in 2005 or did they not meet spec?

The question is rather if there are any immediate plans to implement it for GNOME. Because relying on an interface which is not implemented doesn't seem to be a wise move. It doesn't have to mean anything that this bug was filled if the GNOME developers do not plan to implement it. Maybe some code from Thunar can be used?

I don't have any time to work on my old patches at the moment, feel free to volunteer and improve them! :)

I tried to apply the patch to current nautilus version and suceeded in that (by many hand-fixing), but it doesn't work, and I don't understand the cryptic system of nautilus

Who developed the XDS implementation for Thunar? Maybe this developer can lend us his hand here? Was this patch ever working in the first case, Christian? What has to be done to make it work?

Christian posted his patches on 18/07/2005, i think it was built against HEAD at the time but I guess they're a little old now and won't work against current (2.18) nautilus.

Does this issue rely on just nautilus? or is it more widespread and implemented at the whim of each application developer (i.e. not taken care of by GTK/GNOME)?

Were any of the non local X display issues looked at by any of the core team?

any chance this will make it to GNOME 2.20? (or even a 2.18 backport)

Vytas, might you attach your hand-fixed patch here as well. Thus others might try it out?

Maybe this could have been a good project for the Google Summer of Code.

Adding Benedikt Meurer to the CC list (who seems to having this protocol implemented in Thunar). Benny, can you help us out here perhaps?

Sorry for not contributing anything really helpful, but this PC World Article mentions the GNOME DnD problems (only the File Roller side of it - 102501): http://www.pcworld.com/article/id,128287-c,linux/article.html 

Priority: Enhancement?

Please change priority to HIGH. 
Sure, neither nautilus nor file-roller is broken.
But the gnome-desktop that depends on both these programs is broken.

And perhaps implementing XDS is not a high priority, but doing something so that the default compression program also supports drag and dropping like the rest of the desktop, should have high priority for the next gnome release.

From the users' POV its just broken. 

Sorry not to add anything useful. 

Created attachment 95099 [details] [review]
Working patch against 2.18.1 (adapted from Thunar)

I've adapted the code from Thunar 0.8.0 (code by Benedikt Meurer in thunar-standard-view.c) and created a patch for nautilus 2.18.1.
Only 3 files are concerned: nautilus-file-dnd.c, nautilus-icon-dnd.c, and nautilus-dnd.h.

I've tested it by dragging from File Roller 2.19.90, and it works.

Now, if somebody wants to test the patch against nautilus 2.19.xx :)

Amos, you are my hero!

Amos' patch works here on x86 and amd64 machines (2.18.3) and it applies cleanly to nautilus 2.19.91, but i haven't tested on that machine yet.

Don't forget to send the patch to the nautilus-list@gnome.org mailing list for review (see nautilus/HACKING file).

Just to update, it does work with 2.19.91 as well :) (x86 on that machine)

I've commited XDS support losely based on Amos patch.
However, it doesn't yet support dnd to the list view.

(In reply to comment #44)
> I've commited XDS support losely based on Amos patch.
> However, it doesn't yet support dnd to the list view.
> 

...the code for the drag-n-drop is duplicated: in libnautilus-private there is the code that should manage everything about dnd, but in fact it only manages the icon view. For the list view, the code is partially the same, but is found in with the class implementing the view in the file-manager. 

I think there is already a bug/note that proposes to merge the dnd code, and I think that's the way to fix the problem.

Created attachment 95584 [details] [review]
Treeview XDS support (incremental, depends on my previous patch)

I've ported the XDS code also to the Treeview. The patch I've attached depends on the previous one (because of NAUTILUS_ICON_DND_XDNDDIRECTSAVE and NAUTILUS_ICON_DND_XDNDDIRECTSAVE_TYPE definitions in nautilus-dnd.h)

This patch is against nautilus-2.19.91.

Testers are welcome!

Re comment #2, here is the mozilla bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=396370

I gave a very first go to the implementation, but it needs love and I didn't actually test it with nautilus. Proper download of images from mozilla to nautilus would be nice to have.

FYI, the ubuntu folks implemented a solution for drag & drop from file-roller to nautilus. Not sure if it is real XDS support (above patches) or not, but it works, as of distro release 7.10.

It seems that the patch for XDS support in Tree/List [1] view has not yet been merged (currently looking at nautilus 2.21, on svn/trunk). Without that patch, XDS is only supported in the icon view.

[1] http://bugzilla.gnome.org/attachment.cgi?id=95584

Well, i tried the xds-treeview.patch on Nautilus Nautilus 2.20.0-4 and it worked fine. Thx a lot.

Will it be merged?

Shouldn't the code be modified for the current devel version? It doesn't build.

Setting right patch status and updating fields.
The last patch from Amos applies but doesn't build due to the usage of GnomeVFS functions, which is not used by Nautilus 2.21.x anymore (replaced with GIO/GVfs).

Created attachment 107535 [details] [review]
Treeview XDS support for 2.22.0 (updated to GIO/GVFS) 

I've adapted my previous patch to GIO/GVFS. Tested w/nautilus 2.22.0 (hardy)

Created attachment 107536 [details] [review]
Treeview XDS support for 2.22.0 (updated to GIO/GVFS) 

I've adapted my previous patch to GIO/GVFS. Tested w/nautilus 2.22.0 (hardy)

Hi Amos, could you please send your patch to Nautilus mailing list [1] for review?
I think this is a good feature to get in for 2.24.

[1] nautilus-list@gnome.org

*** Bug 531384 has been marked as a duplicate of this bug. ***

The Treeview XDS support patch is now included in Fedora 10 (rawhide) packages for testing. It's working fine here.

Thanks for your efforts.

I'm fine with the approach in attachment 107536 [details] [review], but instead of the FIXME comment you should update the directory when the drag succeeded, like nautilus-icon-dnd.c:drag_data_received_callback()

I think the patch got lost in the shuffle when it was submitted to nautilus-list@gnome.org on March 18, 2008 by Amos (Thanks Amos!). Anyone want to resubmit it? I would really like to try and get this bug patched before the end of September.

Doh, forgot the original email link:
http://mail.gnome.org/archives/nautilus-list/2008-March/msg00088.html

(In reply to comment #59)
> I think the patch got lost in the shuffle when it was submitted to
> nautilus-list@gnome.org on March 18, 2008 by Amos (Thanks Amos!). Anyone want
> to resubmit it? I would really like to try and get this bug patched before the
> end of September.

The most updated patch is attachment 107536 [details] [review].
Before committing this, we need to address Christian's points in comment #58.

Created attachment 118657 [details] [review]
Rewritten patch

I rewrote the patch to be more in line with NautilusIconContainer's XDS architecture and fixed the issue pointed out in comment 58 myself. The commented hack from attachment for getting the drop position from attachment 107536 [details] [review] has been removed.

We still have one outstanding issue: If the entire container is highlighted for drop with a frame, the frame often is not visible.

Maybe these are some exposure timing issues, it looks like we draw the frame in our tree view exposure handler before the actual tree contents is drawn, which is of course odd.

However, when connecting it with the G_CONNECT_AFTER flag, GtkTreeView's auto-scroll during DND on the top or bottom will move the overlay DND frame into the image, because the region covered by the frame is not invalidated. I experimented a bit, but I was unable to detect XMoveWindow events on the bin window. If anybody knows how to detect auto-scroll events, and invalidate the region covered by the self-drawn highlight frame, it would help a lot - I don't have time to investigate the issue in detail now.

*** Bug 570502 has been marked as a duplicate of this bug. ***

I commited the patch with some fixes. It didn't work when dropping on subdirectories.

Didn't look at the issues pointed out by manny though, so lets keep this open.

I update nautilus today (nautilus-tree-view-drag-dest.c).
"Dropping on subdirectories" works.

Dropping on directories and on subdirectories works in Ubuntu Jaunty, so i guess this is a confirmation that it's fixed.

BUT:

Dropping from file-roller overwrites files without confirmation. Is this a file-roller bug?

It wouldn't hurt to open also a bug against file-roller and set the reference to this bug.

This has become too long to be followed anymore.
Let's close the bug, feel free to open new reports for other issues related to this.