[PATCH] protocol: Add DnD actions

[Carlos Garnacho]

Hey Bill,

On jue, 2015-04-09 at 16:07 -0700, Bill Spitzak wrote:
> On 04/09/2015 03:12 AM, Carlos Garnacho wrote:
> 
> > No, that's precisely why my proposal involves the compositor at 
> > all,
> > the source offers all actions it can handle, after
> > data_device.data_offer/enter, the offer does likewise.
> > 
> > The compositor has then a map of the actions that both parts agree 
> > on,
> > and can toggle actions when the user presses modifier keys, but 
> > these
> > modifier keys should only be honored if both parts recognize such
> > option, it should always fall back into an action that both parts
> > agree on, or the drag will be cancelled. Note that this way the
> > compositor is the sole handler of pointer and keyboard events 
> > during
> > DnD.
> 
> Are you proposing that it is the compositor's job to understand what 
> modifier keys correspond to which actions?
> 
> I think I am failing to describe what I am proposing. Lets try to 
> make 
> this very simple. There are two lists of actions, I'll call them A 
> and 
> B. One of them is from the source, one from the destination. There 
> is a 
> function on A and B that I will call f(A,B) which returns a selected 
> action, which I will call C.
> 
> You are proposing:
> 
>       source sends A to compositor
>       dest sends B to compositor
>       compositor does C = f(A,B)
>       compositor sends C to source
>       compositor sends C to dest
> 
> My proposal:
> 
>       source sends A to compositor
>       compositor sends A to dest
>       dest does C = f(A,B)
>       dest sends C to compositor
>       compositor sends C to source
> 
> The purpose is to move the implementation of f(A,B) out of the 
> compositor and into the clients (removing the transmission of B, 
> which 
> changes rapidly as the target moves between widgets, is also 
> helpful).
> 
> I figured shift keys would work by having the source rearrange the 
> list 
> of actions to put the actions selected by shift first, remove 
> actions 
> prevented by shift, and leave the fallback ones at the end. It 
> assumes 
> the dest will pick the first match.

AFAICT, that assumes that the action is picked when starting the 
operation, and remains static during the operation.

> 
> I think what you are saying is that f() also depends on some state 
> that 
> only the compositor knows. Thus it is f(A,B,state). 

Yes, the state may change during DnD, and so will the final action 
sent to both sides.

> However the 
> compositor could send state along with A to the dest.

This could also work, I however think it makes sense to abstract this a
bit wrt the devices involved. Generally, wl_data_device nicely 
abstracts from the pointer/touch/device being used throughout the 
operation. It makes sense to me to do the same here, if what we are 
pursuing is a DnD action. Also, this IMO gives some degree of liberty 
wrt form factors, testing...

It's true that the modifier mapping becomes compositor-dependent (It's 
been traditionally on toolkit domain), but then so is every keycombo 
the compositor wants to implement.

But I won't be as hard positioned on this one, if the consensus is 
that we better send pressed buttons/modifiers to the dest, it can be 
made to work.

  Carlos