[PATCH] protocol: Add DnD actions

[Carlos Garnacho]

Hey Bill,

On mié, 2015-03-18 at 19:40 -0700, Bill Spitzak wrote:
> This is still bothering me as being much too complicated.

The bad news is, DnD is complex, there's plenty of prior usecases here 
that won't be fair/possible to have "simplified".

> 
> I think a list of actions can be sent from the DnD source to the 
> target, 
> and the target selects one. There is no need for the compositor to 
> do 
> any intersection of the sets and there is no need to communicate the 
> set 
> of target actions to the compositor.
> 
> Your concerns about shift state being handled by the source are 
> misplaced. This would not change at all under what I am proposing, 
> the 
> source could still use the shift state to change the list of actions.

I see several issues with this:

      * How are actions conveyed? do we encode these in the mimetype 
        string? how do we standardize on the actions? how do we make 
        that backwards compatible?
      * How do drag destinations react to unhandled options? Say a 
        drag source appends "?action=ask" when you press Alt and the 
        drag destination only knows copy/move, how does this fallback 
        to an action that both parts recognize?
      * Additionally to modifier state, there's other 
        keyboard/accessibility features as DnD is done in GNOME/GTK+ 
        (eg. DnD driven by cursor keys), these must be implemented on 
        the compositor, this sounds like conflicting with the 
        expectation in your proposal to have the drag source receive 
        key events [1].
> 
> My proposal is basically to take yours, and remove the ability for 
> the 
> target to send a set of actions that the compositor then interesect 
> with 
> the source list. Instead this "intersection" is done by the target, 
> and 
> the target sends *one* action (or "none") indicating the result of 
> the 
> intersection.
> 
> Unless you want the compositor to draw user interface to allow the 
> user 
> to choose the action, which seems very much a bad idea, I cannot see 
> what your proposal will allow to happen that this simplified version 
> would not.

IMO, it kind of misses the point that DnD is a negotiation. 

I was suggesting that the "ask" action were implemented completely by 
the drag destination BTW, that wouldn't change much compared to XDnD.

> 
> I do believe any kind of popup (like a menu for choosing "move or 
> copy") 
> would have to be done by the target. This is because the target may 
> have 
> extra actions that the source does not care about or does not know 
> about, such as "insert" verses "replace". The popup would grab the 
> keyboard focus but when dismissed it may go back to a different 
> client 
> than the target.
> 

Agreed about the grabbing behavior, I'm unclear though on how would 
the actions in such popup work in your proposal: 

Say you start a drag with the special "ask" modifier, and the drag 
source changes its action list to convey "ask" (how exactly? is this 
the only option exposed?). When the destination shows the popup, how 
does it tell the source of the chosen action, so that eg. the 
selection is deleted after "move"?

Cheers,
  Carlos

[1] I'm actually meaning to propose some doc updates with more 
consistent guidelines for grabbing behavior, IMO how do keyboard/touch 
devices behave during the various pointer "grabs" is somewhat 
underdocumented...