[PATCH] protocol: Add DnD actions

[Bill Spitzak]

On 04/10/2015 02:29 AM, Carlos Garnacho wrote:

>> However the
>> compositor could send state along with A to the dest.
>
> This could also work,

Thanks I think I finally made it clear what I am asking for.

So "intersection" is now f(A,B,state), and what I propose is:

     source sends A to compositor
     compositor sends A to dest
     compositor sends state to dest
     dest does C = f(A,B,state)
     dest sends C to compositor
     compositor sends C to source

"compositor sends state to dest" could very well mean that the dest gets 
events for the seat, as though it was temporarily focused. This would 
also allow the dest to make a popup menu to let the user choose an action.

> 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...

Any such concerns like this apply to *all* events, there is nothing 
special about the events during a DnD, and the clients must already have 
code to "abstract wrt the devices involved". The DnD should indicate 
which "seat" is doing the drag however.

> 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.

That seems completely different, as compositor bindings do actions 
without communicating with any client (ie a key that launches a 
particular client will work when there are no clients).

> 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.

Anybody else want to say anything?

I am VERY much in favor of moving as much logic as possible from the 
compositor to the clients. And f(A,B,state) is a very complicated 
function. B may not be a list, it could be, in effect, infinite in size 
(a client conceivably could ask the user to type a filename that the 
drop should go to), can vary quickly (as the user moves across widget 
boundaries), and can contain items the compositor has no business 
knowing about (a paint program may ask how to tile a dropped pattern).

The list A does not vary much and is much shorter IMHO. I think it is 
really move vs copy in almost all cases. Even file linking could be 
considered a "copy" as far as the source is concerned (it does not have 
to know that a link was made rather than the data copied).