[PATCH wayland v4] protocol: Add DnD actions

[Bill Spitzak]

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.

On Fri, Oct 16, 2015 at 8:59 AM, Mike Blumenkrantz <zmike at samsung.com>
wrote:

> On Fri, 16 Oct 2015 16:52:44 +0100
> Daniel Stone <daniel at fooishbar.org> wrote:
>
> > Hi,
> >
> > On Wednesday, 30 September 2015, Carlos Garnacho <carlosg at gnome.org>
> > wrote:
> >
> > > These 2 requests have been added:
> > >
> > > - wl_data_source.set_actions: Notifies the compositor of the
> > > available actions on the data source.
> > > - wl_data_offer.set_actions: Notifies the compositor of the
> > > available actions on the destination side, plus the preferred
> > > action.
> > >
> > > Out of the data from these requests, the compositor can determine
> > > the action
> > > both parts agree on (and let the user play a role through eg.
> > > keyboard modifiers). The chosen option will be notified to both
> > > parties through the following two requests:
> > >
> > > - wl_data_source.action
> > > - wl_data_offer.action
> > >
> > > In addition, the destination side can peek the source side actions
> > > through wl_data_offer.source_actions.
> > >
> > > Compared to the XDND protocol, there's two notable changes:
> > >
> > > - XDND lets the source suggest an action, whereas wl_data_device
> > > lets the destination prefer a given action. The difference is
> > > subtle here, it comes off as convenience because it is the drag
> > > destination which receives the motion events (unlike in X) and can
> > > perform action updates.
> > >
> > >   The drag destination seems also in a better position to update the
> > >   preferred action based on things like the data being transferred,
> > > the place being dropped, and whether the drag is client-local.
> > >
> > > - That same source-side preferred action is used in XDND to convey
> > > the modifier-induced action to the drag destination, which would
> > > then ack it, or reply with another action that's accepted (or
> > > none), this makes the XdndPosition/XdndStatus messaging very
> > > verbose, and synchronous because the drag source always needs to
> > > know the latest status/action for every position+action sent.
> > >
> > >   Here it's the compositor which takes care of modifiers and
> > > matching available/accepted actions, this allows for the signaling
> > > to happen only whenever the actions/modifiers change for real.
> > >
> > > Roughly based on previous work by Giulio Camuffo
> > > <giuliocamuffo at gmail.com <javascript:;>>
> > >
> >
> > Mike had a look at this from EFL - CCing him.
> >
> > Cheers,
> > Daniel
>
> Hi,
>
> Having reviewed this, and also having fully implemented the current DND
> protocol, I think that this is a good idea and would be a worthwhile
> addition. I have no suggestions for modifications or trivial
> bikeshedding.
>
> Regards,
> Mike
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151016/f20538b7/attachment.html>