Hi,<br><br>On Wednesday, 30 September 2015, Carlos Garnacho <<a href="mailto:carlosg@gnome.org">carlosg@gnome.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">These 2 requests have been added:<br>
<br>
- wl_data_source.set_actions: Notifies the compositor of the available<br>
  actions on the data source.<br>
- wl_data_offer.set_actions: Notifies the compositor of the available<br>
  actions on the destination side, plus the preferred action.<br>
<br>
Out of the data from these requests, the compositor can determine the action<br>
both parts agree on (and let the user play a role through eg. keyboard<br>
modifiers). The chosen option will be notified to both parties<br>
through the following two requests:<br>
<br>
- wl_data_source.action<br>
- wl_data_offer.action<br>
<br>
In addition, the destination side can peek the source side actions through<br>
wl_data_offer.source_actions.<br>
<br>
Compared to the XDND protocol, there's two notable changes:<br>
<br>
- XDND lets the source suggest an action, whereas wl_data_device lets<br>
  the destination prefer a given action. The difference is subtle here,<br>
  it comes off as convenience because it is the drag destination which<br>
  receives the motion events (unlike in X) and can perform action updates.<br>
<br>
  The drag destination seems also in a better position to update the<br>
  preferred action based on things like the data being transferred, the<br>
  place being dropped, and whether the drag is client-local.<br>
<br>
- That same source-side preferred action is used in XDND to convey the<br>
  modifier-induced action to the drag destination, which would then ack<br>
  it, or reply with another action that's accepted (or none), this makes<br>
  the XdndPosition/XdndStatus messaging very verbose, and synchronous<br>
  because the drag source always needs to know the latest status/action<br>
  for every position+action sent.<br>
<br>
  Here it's the compositor which takes care of modifiers and matching<br>
  available/accepted actions, this allows for the signaling to happen<br>
  only whenever the actions/modifiers change for real.<br>
<br>
Roughly based on previous work by Giulio Camuffo <<a href="javascript:;" onclick="_e(event, 'cvml', 'giuliocamuffo@gmail.com')">giuliocamuffo@gmail.com</a>><br>
</blockquote><div><br></div><div>Mike had a look at this from EFL - CCing him.</div><div><br></div><div>Cheers,</div><div>Daniel<span></span> </div>