Re: DnD: size limitations?

[Owen Taylor <otaylor redhat com>]

On Sun, 2003-09-14 at 14:38, Lars Wirzenius wrote:
> Background: I'm developing a tool for organizing a photo collection. It
> will have the usual "tree of folders" approach, and supports
> drag-and-drop for moving photographs between folders or "documents" (or
> databases, I guess).
>
> As long as the drag-and-drop is within the same document, I can keep the
> amount of data transferred (i.e., what is returned by the drag-data-get
> signal handler) very small: the operation just updates an internal data
> structure. 
>
> If the drag-and-drop is within the same application instance but between
> documents, I need to copy some files, but I can do that after the
> drag-and-drop finishes, similar to what Nautilus does.

You certainly do want to special-case same-application drag-and-drop.

> If, however, the source and destination documents are open in different
> instances of the application, the only communication channel they have
> open is the drag-and-drop one. If I put lots of data through that
> channel (e.g., all the images), it becomes very slow. I guess that's not
> the way to go? Are there any known limitations on the amount of data one
> should return in drag-data-get? How careful should I be with this?

There's certainly no hard limit. How big you consider to be too slow
is really up to you. 100 bytes is clearly fine. 100meg is going to
be way to slow. Somewhere between is the cross-over...

> Given my situation, what would be a good way to deal with the problem?
>
> a) I could disallow drag-and-dropping outside an application instance,
> but that is a stupid limitation.
>
> b) I could make the assumption that both instances can see the same
> filesystem tree (i.e., fully qualified pathnames in both instances refer
> to the same files) and pass only filenames through drag-and-drop, and
> then have the recipient copy the files afterwards. This would limit what
> you can do with an application that runs from a different machine
> through an ssh pipe, but I think I could live with that.

That might be a a reasonable approach in some circumstances. 

> c) Use a helpful magic solution that is mentioned somewhere in the Gtk
> or Gnome documentation, but which I haven't stumbled on yet.

Well, it would be relatively trivial to speed up GTK+ DND data transfers
by maybe 10-20x. I can provide details to anyone who is interested.

Regards,
                                                Owen