On Thu, 2015-10-01 at 21:36 +0200, Carlos Garnacho wrote: > But this is a very valid concern, if you preemptively accept() with a > random mimetype, the user quickly finishes the drag before transfers > are done, and it isn't accepted in the end, you'd get the wrong > feedback, and the wrong outcome in move operations, where the source > may think it's ok to delete the data. The other option is not > accept()ing until the first transfer is done like you do right now, > and train the user to wait long enough on huge dnd transfers, so > early > drops turn out cancelled. There'd usually be at least cursor feedback > from the drag source when accept() finally happens. Both options are > somewhat disconcerting, I admit...
I was thinking we should go with the second option (i.e. the current behavior of your patches), because I can't think of any way to avoid the problems you bring up. But there is another problem: when Chrome sends accepts, they are not necessarily intended for the current coordinates of the pointer. There is a round-trip needed between the GPU process (which uses Wayland) and the browser process (which makes decisions about where stuff is allowed to be dropped). So by the time the GPU process receives from the browser process the instruction to send the accept, another motion event(s) could have occurred, and the accept would be stale. It's easy to detect that occurrence, but not avoid it, because the only thing to do would be to drop stale accepts, and that could result in there being no drag feedback at all until the pointer stops. Currently, that's no problem because a new accept will be coming soon, and the accepts don't affect correctness. But now this too could cause a drop to fail on the destination side, when the source side thinks the drop has succeeded! > I meant, adding a separate .set_droppable() request with a boolean > parameter that indicates success, so .accept()'s role remains > unchanged. There's the downside that you decouple source-side > feedback > from the rest of the DnD operation outcome (compositor-side feedback > and events emitted). Again, this is something that happens on XDND, > eg. by acknowledging one status on XdndStatus and finishing with > another one on XdndFinished, feels like late 90's again :). What would be the point of a separate .set_droppable() request? I don't see what problem that would solve. Thanks, Michael _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
