On Fri, Oct 30, 2015 at 7:10 PM, Bill Spitzak <spit...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
