[PATCH] protocol: Add DnD actions

Thu Apr 16 01:15:06 PDT 2015

Hi,

Disclaimer: I don't know much how XDND works, but have some comments
anyway. See below:

On Sat, Apr 11, 2015 at 12:59:48PM +0200, Carlos Garnacho wrote:
> 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'd have to agree on that it doesn't seem like the best thing to let the
compositor choose the preferred action. Having it apply compositor
specific policy given what the keyboard state or similar will probably
never work out very well, given that for example what modifier state
means what type of action is very application dependent.

On the other hand, I'm not sure we can currently rely on either side
having keyboard focus during the drag. In weston the source will have the
focus because starting the drag was done with a click which gave the
surface keyboard focus implicitly, but what'd happen if the compositor
has keyboard-focus-follows-mouse? We could probably say that drag implies
an implicit grab on another device on the same seat to enforce no
changing of keyboard focus, but not sure that is better.

I also don't see the variable state to be a good thing considering we'd
have three independent states, meaning it'd get a very racy and
non-deterministic protocol.

If we'd want to have the destination choose the action, the source
should advertise its possible actions, forwarded by the compositor to
the destination ("atomically", without intermediate committed state).

If we want to enable one of the clients to rely on keyboard modifier
state, I think this should be communicated to the deciding end point;
which I suspect is what Bill is talking about regarding  the 'state'
that is sent from the compositor.

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

For clarification: I think that mime types should be considered a
non-varying static set. They are advertised after creating the data
source before the data source is enabled (via set_selection or
start_drag). The destination will only receive the mime types as one
batch before the offer being enabled (via enter or selection). This might
be less than clearly written in the protocol, but its my understanding of
it (see for example the wl_data_device.data_offer documentation).

Jonas

> 
> > 
> > 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel