Bug#532773: Nautilus has incomplete support for XDS DND

[jdietrch at fastmail.fm]

Package: nautilus
Version: 2.26.2-5
Tags: patch

Background:
This bugreport concerns nautilus' support for XDS. For more information
about what XDS is and the standard for implementing it, see
http://www.newplanetsoftware.com/xds/

Short version:
Nautilus doesn't implement the "F" fallback in the XDS standard.

Long version:
Nautilus has support for XDS, but it is not complete. In particular, it
does not support the "F" fallback. The XDS standard outlines two ways
for the file to be saved: (1) The source application does all the work
of saving the file, with the file manager only providing the full URI
where the file should be saved. (2) If the source application can't or
won't save the file, the file manager should request the raw data (type
application/octet-stream) from the source and then save the file itself.

Number (2) is important because the source application may be running on
a remote machine and have no way to do the work of saving the file.
However, nautilus only implements only (1). The end result is that
nautilus does not accept XDS drops from an application that can't or
won't do all the work of saving the file.

Proposed solution:
One of my projects needed to have a file manager that fully implements
XDS. The file manager rox-filer worked fine, but I really wanted to use
nautilus. So I created a patch to make nautilus fully implement the XDS
standard. The file is attached, and it worked fine for me when added to
the quilt series in debian/patches.

Here are the main features of the patch: When handling an XDS drop, if
the source sends the "F" fallback, then nautilus immediately requests
the raw data in application/octet-stream format. Of course, nautilus
then needs to be able to handle drops of raw data, so the patch adds
that support as well. And since the raw data likely contains embedded
nul bytes, a GString is used to hold the data instead of a char *.

A simple test program written in Python is attached. Dragging the top
button to nautilus should create a file named 'tar' in the drop location
which should be identical to the file '/bin/tar'. This tests the full
implementation of the XDS standard. Dragging the bottom button should
create a file named 'dropped data' in the drop location which also
should be identical to the file '/bin/tar'. This does *not* use XDS; it
just tests nautilus' acceptance of raw data (type
application/octet-stream). BTW, nothing special about /bin/tar; it's
just a hard-coded example that I supposed everyone would have.

Let me know if you have any questions, or if there's anything else I can
do to help.

Thanks,
James Dietrich
-- 
  
  jdietrch at fastmail.fm

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 30_complete_xds_support.patch
Type: text/x-patch
Size: 25694 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20090611/79adb38e/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dnd.py
Type: text/x-python
Size: 3973 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20090611/79adb38e/attachment-0001.py>