After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 171655 - add support for XDS (Direct Save protocol) to list view
add support for XDS (Direct Save protocol) to list view
Product: nautilus
Classification: Core
Component: File and Folder Operations
Other All
: High enhancement
: 2.24.x
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 531384 570502 (view as bug list)
Depends on:
Blocks: 102501 301072 319969 402317
Reported: 2005-03-25 22:42 UTC by Sven Neumann
Modified: 2011-03-31 19:27 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement

Proposed (prelimitary) patch against HEAD (30.67 KB, patch)
2005-07-18 18:33 UTC, Christian Neumair
none Details | Review
nautilus-xds-dnd.c (4.51 KB, text/plain)
2005-07-18 18:35 UTC, Christian Neumair
nautilus-xds-dnd.h (1.73 KB, text/plain)
2005-07-18 18:35 UTC, Christian Neumair
Working patch against 2.18.1 (adapted from Thunar) (8.99 KB, patch)
2007-09-07 02:04 UTC, Amos Brocco
committed Details | Review
Treeview XDS support (incremental, depends on my previous patch) (6.98 KB, patch)
2007-09-14 11:40 UTC, Amos Brocco
none Details | Review
Treeview XDS support for 2.22.0 (updated to GIO/GVFS) (6.97 KB, patch)
2008-03-18 14:23 UTC, Amos Brocco
none Details | Review
Treeview XDS support for 2.22.0 (updated to GIO/GVFS) (6.97 KB, patch)
2008-03-18 14:24 UTC, Amos Brocco
needs-work Details | Review
Rewritten patch (6.85 KB, patch)
2008-09-13 13:27 UTC, Christian Neumair
none Details | Review

Description Sven Neumann 2005-03-25 22:42:37 UTC
The XDS spec ( describes an extension to
the XDND protocol that allows applications to save files by dropping them on the
desktop or on a file manager.

As of today, GIMP supports this protocol (in the HEAD branch). It would be nice
if nautilus would implement the other side of the protocol so that GIMP users
could save images by dragging them to the GNOME desktop or to nautilus folders.

Here are some links that you might find useful:
Comment 1 Sven Neumann 2005-03-25 22:48:16 UTC
Not to forget this one:
Comment 2 Reinout van Schouwen 2005-04-19 12:54:16 UTC
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.
Comment 3 Christian Neumair 2005-07-11 14:42:45 UTC
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.
Comment 4 Sven Neumann 2005-07-11 19:21:38 UTC
The protocol is actually rather straight-forward and you won't need any XLib
calls, the GDK property and selection APIs should be sufficient.
Comment 5 Christian Neumair 2005-07-11 19:26:14 UTC
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.?
Comment 6 Sven Neumann 2005-07-11 19:33:44 UTC
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 ? What exactly is not clear about it?
Comment 7 Christian Neumair 2005-07-11 19:37:27 UTC
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* ;).
Comment 8 Christian Neumair 2005-07-18 18:33:36 UTC
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".
Comment 9 Christian Neumair 2005-07-18 18:35:00 UTC
Created attachment 49362 [details]
Comment 10 Christian Neumair 2005-07-18 18:35:17 UTC
Created attachment 49363 [details]
Comment 11 Christian Neumair 2005-07-18 18:44:29 UTC
I just noted that the two "cb" callbacks are not connected. Maybe we should
reveal the icons there if successfull.
Comment 12 xavier.bestel 2005-10-03 14:13:28 UTC
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 ?
Comment 13 Rich Wareham 2005-10-15 16:22:30 UTC
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.
Comment 14 Christian Neumair 2005-10-15 20:52:28 UTC
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?
Comment 15 xavier.bestel 2005-10-15 23:55:19 UTC
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.
Comment 16 Christian Neumair 2005-10-16 07:07:59 UTC
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
Comment 17 xavier.bestel 2005-10-16 20:35:14 UTC
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.
Comment 18 Christian Neumair 2005-11-11 08:22:21 UTC
I've filed bug 321211, which deals with implementing XDS at GTK+ level.
Comment 19 Christian Neumair 2005-11-11 08:23:22 UTC
Note that bug 319969, which deals with panel/nautilus launcher dragging could
also be fixed by using the XDS protocol.
Comment 20 Raphaël Quinet 2005-12-20 13:21:11 UTC
Regarding comment #16 and comment #17: both protocols (XDS and XDND) require
the file:// URI to contain a host name.  See this reference:
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:
Comment 21 Reinout van Schouwen 2006-01-02 15:52:47 UTC
Raphaël: the missing host name in the URI is bug 44725.
Comment 22 amano 2006-12-30 23:06:16 UTC
If I get the comment right, Ubuntu Launchpad Bug #13199 (the infamous file roller bug) depends now on this. See for further reference.
Comment 23 amano 2006-12-30 23:24:19 UTC
(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
> for further
> reference.

The first link was auto-generated and is wrong of course. The second links takes you to the relevant launchpad bug.
Comment 24 amano 2006-12-31 03:31:49 UTC
The relevant file-roller bug which depends on this bug is BTW. And sorry for the spam.
Comment 25 Jean-François Fortin Tam 2007-02-05 05:14:35 UTC
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 :)
Comment 26 Ralf.Nieuwenhuijsen 2007-03-01 02:29:29 UTC
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 ;-)
Comment 27 amano 2007-03-02 11:47:50 UTC
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?
Comment 28 Thomas Leonard 2007-03-03 09:56:25 UTC
What about Archive? It's from the ROX project:

It has a very simple interface:

1. Drag a directory to it, and then drag the compressed archive out.
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 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)
Comment 29 Nick G 2007-03-03 10:57:41 UTC
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?
Comment 30 amano 2007-03-12 19:36:45 UTC
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?
Comment 31 Christian Neumair 2007-03-13 22:09:20 UTC
I don't have any time to work on my old patches at the moment, feel free to volunteer and improve them! :)
Comment 32 Vytas 2007-04-11 13:52:18 UTC
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
Comment 33 amano 2007-04-12 17:54:58 UTC
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?
Comment 34 Nick G 2007-04-12 18:06:19 UTC
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)
Comment 35 amano 2007-04-13 03:18:36 UTC
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.
Comment 36 amano 2007-04-13 17:20:51 UTC
Adding Benedikt Meurer to the CC list (who seems to having this protocol implemented in Thunar). Benny, can you help us out here perhaps?
Comment 37 amano 2007-07-17 22:04:26 UTC
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):,128287-c,linux/article.html 
Comment 38 Ralf.Nieuwenhuijsen 2007-07-18 18:59:56 UTC
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. 
Comment 39 Amos Brocco 2007-09-07 02:04:53 UTC
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 :)
Comment 40 Steev Klimaszewski 2007-09-07 05:17:28 UTC
Amos, you are my hero!
Comment 41 Steev Klimaszewski 2007-09-07 14:03:28 UTC
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.
Comment 42 Christian Persch 2007-09-08 20:35:36 UTC
Don't forget to send the patch to the mailing list for review (see nautilus/HACKING file).
Comment 43 Steev Klimaszewski 2007-09-09 09:04:14 UTC
Just to update, it does work with 2.19.91 as well :) (x86 on that machine)
Comment 44 Alexander Larsson 2007-09-10 10:47:43 UTC
I've commited XDS support losely based on Amos patch.
However, it doesn't yet support dnd to the list view.

Comment 45 Amos Brocco 2007-09-12 11:52:27 UTC
(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.
Comment 46 Amos Brocco 2007-09-14 11:40:38 UTC
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!
Comment 47 Marco Pesenti Gritti 2007-09-16 21:00:58 UTC
Re comment #2, here is the mozilla bug:

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.
Comment 48 Ariel 2007-12-16 22:07:50 UTC
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.
Comment 49 Amos Brocco 2008-01-03 23:23:34 UTC
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.


Comment 50 NewC 2008-01-17 22:13:12 UTC
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?
Comment 51 Timo Aaltonen 2008-03-06 08:32:14 UTC
Shouldn't the code be modified for the current devel version? It doesn't build.
Comment 52 Cosimo Cecchi 2008-03-06 09:30:22 UTC
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).
Comment 53 Amos Brocco 2008-03-18 14:23:34 UTC
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)
Comment 54 Amos Brocco 2008-03-18 14:24:20 UTC
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)
Comment 55 Cosimo Cecchi 2008-03-18 14:41:12 UTC
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.

Comment 56 Cosimo Cecchi 2008-05-04 18:12:38 UTC
*** Bug 531384 has been marked as a duplicate of this bug. ***
Comment 57 Tomas Bzatek 2008-05-19 15:05:09 UTC
The Treeview XDS support patch is now included in Fedora 10 (rawhide) packages for testing. It's working fine here.
Comment 58 Christian Neumair 2008-07-17 20:13:21 UTC
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()
Comment 59 Daniel Roesler 2008-09-07 17:28:44 UTC
I think the patch got lost in the shuffle when it was submitted to 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.
Comment 60 Daniel Roesler 2008-09-07 17:30:35 UTC
Doh, forgot the original email link:
Comment 61 Cosimo Cecchi 2008-09-07 17:32:04 UTC
(In reply to comment #59)
> I think the patch got lost in the shuffle when it was submitted to
> 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.
Comment 62 Christian Neumair 2008-09-13 13:27:59 UTC
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.
Comment 63 Cosimo Cecchi 2009-02-04 20:27:19 UTC
*** Bug 570502 has been marked as a duplicate of this bug. ***
Comment 64 Alexander Larsson 2009-03-16 15:59:07 UTC
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.
Comment 65 David Liang 2009-03-26 09:13:44 UTC
I update nautilus today (nautilus-tree-view-drag-dest.c).
"Dropping on subdirectories" works.
Comment 66 Jakob Unterwurzacher 2009-04-29 15:16:28 UTC
Dropping on directories and on subdirectories works in Ubuntu Jaunty, so i guess this is a confirmation that it's fixed.


Dropping from file-roller overwrites files without confirmation. Is this a file-roller bug?
Comment 67 Baptiste Mille-Mathias 2009-04-29 15:24:32 UTC
It wouldn't hurt to open also a bug against file-roller and set the reference to this bug.
Comment 68 Cosimo Cecchi 2011-03-31 19:27:36 UTC
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.