RFC: Drag and drop actions
carlosg at gnome.org
Mon Feb 16 07:37:33 PST 2015
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
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.
More information about the wayland-devel