Hey everyone, I'm bringing again on the table a proposal for DnD actions in the protocol, this is something I feel missing for complete parity with XDND, at least seeing the missing bits from the GNOME perspective.
I picked the earlier work from Giulio Camuffo, although perhaps ended up not being too similar. Here, the compositor plays a role in the chosen action, after both ends have gotten to notify their supported ones. This also caters for the case where keyboard modifiers may change the current action. As for the available actions, I finally sticked to the copy/move/ask semantics, even though they're not most descriptive maybe. IMO, all that matters on the source side is whether the data should be deleted afterwards, and (mainly) on the destination side whether the DnD operation would be prolonged by some ask mechanism. Going to the basics, "link" is a kind of "copy", "drop to execute" would be too, what the operation really is should just matter to the destination side. But I think this caters for some known-broken cases around GNOME: - DnD within a text widget defaults to move, dropping anywhere else defaults to copy. The destination side would just update the preferred action on wl_data_device.motion - Middle click DnD in nautilus defaulting to "ask". The source would set "ask" as the single allowed action. - The current action being modifiable through ctrl/alt/shift modifiers. This can be implemented by the compositor. Other additions to the protocol are the "drop_performed" and "finished" events on wl_data_source. Knowing the selected mimetype and action, the compositor is in a much better situation to emit "cancelled" if some of these is "dunno", these two events become most useful on "ask" though, as the DnD operation has different termination phases, they would be emitted on every successful drop operation though. Some additional notes to consider: - The actions mechanism would potentially fall apart if there are multiple concurrent offers on a same data source, and different actions are notified on each of these. I know we just advise to destroy the offer on wl_data_device.leave, and I at the moment made weston stick to the last created offer, would we better define/emit errors if an older offer is being manipulated? - So far, it's been left unspecified what happens about the pointer surface during DnD, this is more pressing now that it can potentially change based on the "action" events. On weston, the pointer surface still seems driven by the drag source. If we're to keep the actions somewhat abstract, would be the drag destination in a better position to offer the right context? I guess dest side cursors could be a potential data loss problem with destination sides actually "moving" data, but not providing an icon that convey so. Those cases should be easy to point out though. Cheers, Carlos _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
