[PATCH wayland] protocol: Improve data source notification around DnD progress

[Carlos Garnacho]

On Fri, Oct 30, 2015 at 7:10 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> I think what is wanted is an indication that the drag really did finish. For

That's data_source.drag_finished in the patch you're commenting.

> instance a file browser acting as the source of a "move" action will want a
> confirmation that the move actually worked before it actually destroys the
> source file. This confirmation can happen long after the dnd action is
> negotiated and after all the data is transferred. Imagine if the destination
> suddenly encounters an error trying to write the file to the destination
> disk. It does seem like toolkits are purposely delaying messages that were
> designed to be sent asap in other DnD protocols in order to achieve this.

This is not how file managers implement this.

Only the URIs and the intent are transferred through DnD, file
managers are then smart enough to:

- Implement move as rename(2) when moving across the same filesystem,
implementing it as copy+delete across filesystems. Note that the
former is atomic and doesn't need any counteroperation on the source
side.
- Ignore move operations on the source side if dnd'ing from the file
manager into other application than itself (or rather, always). If
someone moves/deletes the file, it will be the drag destination.

Stalling the DnD operation/data for as long as the file transfer
endures (which is completely off-band, nothing the wayland protocol
cares about) is as dubious as it is transferring the actual file data
through the pipe, plus it'll be probably useless/outdated in the case
of late transfer failure. "move" as a finite operation makes only
sense in the context of the data being known to wayland (i.e. the one
sent across source/offer), the client is of course free to make a
different sense of it.

Cheers,
  Carlos