On Sun, 2009-06-14 at 19:38 -0400, James Dietrich wrote: > As I recently added XDS support to the application I am developing, > I needed a file manager that also supported XDS. It was a bit > surprising to discover that nautilus doesn't currently implement > the full XDS standard (http://www.newplanetsoftware.com/xds/). > In particular, nautilus doesn't support the "F" fallback of XDS, > which allows the file manager to receive the data for the dropped > file via the X server and save the file. This is important to me, > because my application is run on a remote machine, and cannot save > files to the local machine. It depends on the "F" fallback to get > the file saved. > > So I patched nautilus to fully support XDS and opened this bug > report with a full description. I have also attached the patch and > a test program. See http://bugzilla.gnome.org/show_bug.cgi?id=585790 > > Since I use Debian, I first reported this to the Debian bug tracking > system. But the package maintainer suggested that it would be better > to discuss this directly with upstream. So that's what I'm doing. > I'd love to see this feature included in the upstream source. It would > certainly be useful to me, as well as to anyone else who uses XDS with > an app running on a remote machine. > > Questions? Suggestions? Anything else I can do to help?
I'm not sure why you changed the APIs to use GString. I don't think that really helps, it just means we have to duplicate the data in various places. I'd prefer to add a length argument to the functions you made accept a GString. Also, it seems like we're allocating memory for the whole file before saving. Thats gonna be kinda bad for large files. Also, do we really pass all that data as a single x message? Minor nits: There is a bunch of missing spaces before parenthesis in function calls. -- nautilus-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/nautilus-list
