[PATCH] protocol: Add DnD actions

[Bill Spitzak]

On 04/18/2015 07:53 AM, Carlos Garnacho wrote:

Let me try to correct this by removing some unnecessary data. In 
particular no list of actions is sent by the destination. Also there is 
no need for the compositor to echo the selected action back to the 
destination. More importantly I have added "update the user interface" 
requests from both source an destination, to make round-trips more clear 
(this includes changing the cursor and changing graphics in the surfaces):

2. If handled purely by the dest:

wl_data_source      compositor            wl_data_offer
==============      ==========            =============
                   -> notify_actions
                                         -> source_actions
                      action             <-
                      update_ui          <-
action           <-
                  ->  update_ui
                          ...
                                            (pointer moves across widgets)
                      action             <-
                      update_ui          <-
action           <-
                  ->  update_ui
                          ...
                      (modifiers change)
                                         -> modifiers
                      action             <-
                      update_ui          <-
action           <-
                  ->  update_ui

For reference here is your proposal. You seem to have added sending the 
source actions to the destination and allowing that to edit the dest 
action list, over what you originally proposed. I am not sure if this is 
a copy+paste error or you actually mean it to be there, I marked it with 
"new??"

wl_data_source      compositor            wl_data_offer
==============      ==========            =============
                   -> notify_actions
                                         -> source_actions ### new??
                      notify_actions     <-
action           <-                     -> action
                      update_ui          <-
                  ->  update_ui
                          ...
                                            (pointer moves across widgets)
                      notify_actions     <-
action           <-                     -> action
                      update_ui          <-
                  ->  update_ui
                          ...
                      (modifiers change)
action           <-                    -> action
                      update_ui         <-
                  ->  update_ui

> Options #1 and #2 involve roundtrips, option #3 doesn't.

Sorry I don't see this. I was going to say that they are exactly the 
same, but I now see that #2 has one less round trip on the destination 
side for the pointer-moved case (it can update the display 
simultaneously with sending the selected action, while yours requires it 
to wait for a response after sending the notify actions). So it wins there.

Though your version has the same number of round trips for 
modifier-changed, they can be done simultaneously, while #2 requires 
them to be done serially. So your version wins there.

I believe the mouse is moved more often than the modifiers are changed, 
thus in total proposal #2 has fewer round trips.

> Options #1
> and #2 would still need some validation on the compositor to avoid
> picking options unknown to either side.

Option 3 has to "validate" in that it has to do something if there is no 
intersection of the lists. And I think you could consider the whole 
"intersect the lists and choose based on modifier keys" a very large 
"validation" function.

Not only that, I am pretty certain it would be harmless to send whatever 
action the dest chose to the source without any checking at all, thus 
the "validation" concern is moot. The source can check it pretty easily. 
You are not saving anything as sources will have many other failure 
modes (such as async deletion of the source data while the drag is 
happening) and this is a trivial addition.