RFC: Drag and drop actions

[Carlos Garnacho]

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