[PATCH wayland] protocol: Improve data source notification around DnD progress

[Jonas Ådahl]

Hey Carlos,

Finally had a look at this one.

On Wed, Sep 30, 2015 at 10:45:39PM +0200, Carlos Garnacho wrote:
> Currently, there's no means for the DnD origin to know whether the
> destination is actually finished with the DnD transaction, short of
> finalizing it after the first transfer finishes, or leaking it forever.
> 
> But this poses other interoperation problems, drag destinations might
> be requesting several mimetypes at once, might be just poking to find
> out the most suitable format, might want to defer the action to a popup,
> might be poking contents early before the selection was dropped...
> 
> In addition, data_source.cancelled is suitable for the situations where
> the DnD operation fails (not on a drop target, no matching mimetypes,
> etc..), but seems undocumented for that use (and unused in weston's DnD).
> 
> In order to improve the situation, the drag source should be notified
> of all stages of DnD. In addition to documenting the "cancelled" event
> for DnD purposes, The following 2 events have been added:
> 
> - wl_data_source.drop_performed: Happens when the operation has been
>   physically finished (eg. the button is released), it could be the right
>   place to reset the pointer cursor back and undo any other state resulting
>   from the initial button press.
> - wl_data_source.drag_finished: Happens when the destination side destroys
>   the wl_data_offer, at this point the source can just forget all data
>   related to the DnD selection as well, plus optionally deleting the data
>   on move operations.
> 
> Signed-off-by: Carlos Garnacho <carlosg at gnome.org>
> ---
>  protocol/wayland.xml | 34 +++++++++++++++++++++++++++++-----
>  1 file changed, 29 insertions(+), 5 deletions(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 42c9309..1ee143f 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -408,7 +408,7 @@
>    </interface>
>  
>  
> -  <interface name="wl_data_offer" version="1">
> +  <interface name="wl_data_offer" version="3">
>      <description summary="offer to transfer data">
>        A wl_data_offer represents a piece of data offered for transfer
>        by another client (the source client).  It is used by the
> @@ -463,7 +463,7 @@
>      </event>
>    </interface>
>  
> -  <interface name="wl_data_source" version="1">
> +  <interface name="wl_data_source" version="3">
>      <description summary="offer to transfer data">
>        The wl_data_source object is the source side of a wl_data_offer.
>        It is created by the source client in a data transfer and
> @@ -510,14 +510,38 @@
>  
>      <event name="cancelled">
>        <description summary="selection was cancelled">
> -	This data source has been replaced by another data source.
> +	This data source is no longer valid. There are several reasons why
> +	this could happen:
> +
> +	- The data source has been replaced by another data source.
> +	- The drop operation finished, but the drop destination did not
> +	  accept any of the mimetypes offered through data_source.target.
> +	- The drop operation finished but didn't happen over a DnD target.

That the "operation finished" sounds like the transfer was done as well.
"The drop was performed" maybe is better?

> +
>  	The client should clean up and destroy this data source.
>        </description>
>      </event>
>  
> +    <!-- Version 3 additions -->
> +
> +    <event name="drop_performed" since="3">
> +      <description summary="the drag-and-drop operation physically finished">
> +	The user dropped this data onto an accepting destination. Note
> +	that the data_source will be used further in the future and should
> +	not be destroyed here.
> +      </description>
> +    </event>

I too would like some clarifications why this is needed. The cursor and
button state, I assume, could be reset on the next enter or by
cancelled/finished, but that the client may want update its UI in some
way.

This also, as discussed in another part of this thread, adds
requirements on the destination "accepting" an offer. It'd also be good
with clarifications about what would happen if a offer accepted an
offer at one position, but the drop was performed on another, where the
destination do not accept. Would one still get a cancelled then?

Maybe also add a paragraph to wl_data_offer.accept?

> +
> +    <event name="drag_finished" since="3">
> +      <description summary="the drag-and-drop operation finished">
> +	The drop destination finished interoperating with this data
> +	source, the client is now free to destroy this data source and
> +	free all associated data.
> +      </description>
> +    </event>
>    </interface>

"drag_" finished sounds a bit odd to me. I guess its meant to namespace
the event as a drag-and-drop event?

Correct me if I'm wrong, but this event is meant to be sent after a
destination has read all the data it needs, meaning we could effectively
send this for regular clipboard sources as well? Then just call it
"finished".

Thats all I have now.


Jonas

>  
> -  <interface name="wl_data_device" version="2">
> +  <interface name="wl_data_device" version="3">
>      <description summary="data transfer device">
>        There is one wl_data_device per seat which can be obtained
>        from the global wl_data_device_manager singleton.
> @@ -659,7 +683,7 @@
>      </request>
>    </interface>
>  
> -  <interface name="wl_data_device_manager" version="2">
> +  <interface name="wl_data_device_manager" version="3">
>      <description summary="data transfer interface">
>        The wl_data_device_manager is a singleton global object that
>        provides access to inter-client data transfer mechanisms such as
> -- 
> 2.5.0
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel