[PATCH] protocol: Add DnD actions

[Carlos Garnacho]

On vie, 2015-04-10 at 12:44 -0700, Bill Spitzak wrote:
> 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.

In fairness, your proposal started as something quite different, we 
happened to find the middle ground.

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

DnD can be driven by mouse, touch, and stili when wl_tablet arrives. 
There's however no exposure of this on the events sent by data_device, 
everything happens in its own semantics rather than wl_pointer's or 
wl_touch's. I'm not sure why the actions derived from keyboards 
deserve a different treatment.

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

Are you maybe folding mimetypes and actions as A/B/C above? The only 
thing that can grow "unbounded" is the mimetype list, the possible 
actions are always a fixed set, and resolved after the mimetype is 
negotiated. AFAICS "B" corresponds to the dest side, which confuses 
me, because both the picked mimetype and action will always be a 
subset of A's.

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

Ah, I see, perhaps it's rather "varying over time" than "infinite"? 
TBH I don't see how this is different to how mimetypes are dealt with, 
you definitely don't have to calculate all possible states at once, 
just for the position you're in.

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


Cheers,
  Carlos