[PATCH] protocol: Add DnD actions

[Carlos]

Hi Bill,

On Mon, Feb 16, 2015 at 10:17 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> I would think the drop target client can figure out what action to perform,
> there is no need to communicate it's set of actions to the compositor or for
> the compositor to have any of this logic to "determine the action both parts
> agree on".

I unfortunately think such simple approach won't cover all usecases
I'm intending to, most notably the user role in action selection.

On XDND, it is the DnD source app which keeps keyboard/pointer grabs,
and orchestrates all DnD message interaction with the DnD destination,
all it must do there is updating the "suggested action" based on the
currently pressed modifiers.

On wayland, it is true that the semantics of compositor-side device
grabs are mostly up to the compositor, but delegating this on the
destination client means we need to start sending
wl_keyboard.modifiers to random unfocused clients. Compositors may
also want, for accessibility reasons, to let DnD to be driven by
keyboard (eg. cursor keys), so you end up performing selective
treatment of key events, I hope you see why I think this soon becomes
irksome.

With my proposed action system, in exchange for having the compositor
play a minimal role in this (basically ANDing the options and picking
one), we get the compositor doing all of this, and clients sticking to
wl_data_[source|offer] events/requests, which I find more consistent.

>
> The drop target will have to say what action it did. It also sounds like you
> are concerned that the source may want to know the action on drag events so
> the source can update the cursor or redraw the source location to show the
> result of the action. But this is only one action, not a list.

Yes, the "action" events must have just one bit set, after the
compositor picked the current action. The cursor icon would be
something that changes during the DnD operation, say attempting a drop
on local vs remote drives on the file manager (with different move vs
copy preferred actions), or user modifications.

>
> So basically it seems like any lists from the drop target can be avoided.
> The drop target would only send a single action.

It could, if it were to know the available actions from the drag
source. Given my concerns with the move/copy/ask semantics, I
preferred to keep both isolated in that regard. Matching the actions
in the compositor also gives a solid place where you can just emit
wl_data_source.cancelled on failed drags, which is not as clear if the
compositor is merely the carrier here.

>
> The compositor can throw a protocol error if the client sends an action that
> is not in the list. Or it could just convey it right through and let the
> drag source client ignore it.

On this proposal, the drag source would recevice wl_data_source.action
with 0, it may also want to set the pointer surface to a "forbidden"
sign or somesuch.

  Carlos