<div dir="ltr"><div><div>I wish to formally state that I very seriously believe this proposal is wrong. The action must be decided by the destination client, not the way this is trying to do it.<br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 16, 2015 at 8:59 AM, Mike Blumenkrantz <span dir="ltr"><<a href="mailto:zmike@samsung.com" target="_blank">zmike@samsung.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, 16 Oct 2015 16:52:44 +0100<br>
Daniel Stone <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> On Wednesday, 30 September 2015, Carlos Garnacho <<a href="mailto:carlosg@gnome.org">carlosg@gnome.org</a>><br>
> wrote:<br>
><br>
> > These 2 requests have been added:<br>
> ><br>
> > - wl_data_source.set_actions: Notifies the compositor of the<br>
> > available actions on the data source.<br>
> > - wl_data_offer.set_actions: Notifies the compositor of the<br>
> > available actions on the destination side, plus the preferred<br>
> > action.<br>
> ><br>
> > Out of the data from these requests, the compositor can determine<br>
> > the action<br>
> > both parts agree on (and let the user play a role through eg.<br>
> > keyboard modifiers). The chosen option will be notified to both<br>
> > parties 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<br>
> > through 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<br>
> > lets the destination prefer a given action. The difference is<br>
> > subtle here, it comes off as convenience because it is the drag<br>
> > destination which receives the motion events (unlike in X) and can<br>
> > 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,<br>
> > the place being dropped, and whether the drag is client-local.<br>
> ><br>
> > - That same source-side preferred action is used in XDND to convey<br>
> > the modifier-induced action to the drag destination, which would<br>
> > then ack it, or reply with another action that's accepted (or<br>
> > none), this makes the XdndPosition/XdndStatus messaging very<br>
> > verbose, and synchronous because the drag source always needs to<br>
> > know the latest status/action for every position+action sent.<br>
> ><br>
> >   Here it's the compositor which takes care of modifiers and<br>
> > matching available/accepted actions, this allows for the signaling<br>
> > to happen only whenever the actions/modifiers change for real.<br>
> ><br>
> > Roughly based on previous work by Giulio Camuffo<br>
</div></div>> > <<a href="mailto:giuliocamuffo@gmail.com">giuliocamuffo@gmail.com</a> <javascript:;>><br>
<span class="">> ><br>
><br>
> Mike had a look at this from EFL - CCing him.<br>
><br>
> Cheers,<br>
> Daniel<br>
<br>
</span>Hi,<br>
<br>
Having reviewed this, and also having fully implemented the current DND<br>
protocol, I think that this is a good idea and would be a worthwhile<br>
addition. I have no suggestions for modifications or trivial<br>
bikeshedding.<br>
<br>
Regards,<br>
Mike<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br></div>