On Tue, Dec 22, 2015 at 02:33:32AM +0100, 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.dnd_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.dnd_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. > > Changes since v4: > - Applied rewording suggestions from Jonas Ådahl. Added new > wl_data_offer.finish request to allow explicit finalization on the > destination side. > > Changes since v3: > - Renamed dnd_performed to a more descriptive dnd_drop_performed, > documented backwards compatible behavior on wl_data_offer.accept and > wl_data_source.cancelled. > > Changes since v2: > - Minor rewording. > > Changes since v1: > - Renamed events to have a common "dnd" namespace. Made dnd_performed to > happen invariably, data_device.cancelled may still happen afterwards. > > Signed-off-by: Carlos Garnacho <carl...@gnome.org> > Reviewed-by: Michael Catanzaro <mcatanz...@igalia.com> > Reviewed-by: Jonas Ådahl <jad...@gmail.com> > Reviewed-by: Mike Blumenkrantz <zm...@samsung.com> > --- > protocol/wayland.xml | 75 > +++++++++++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 69 insertions(+), 6 deletions(-) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index df8ed19..ae5ef21 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 > @@ -423,7 +423,17 @@ > Indicate that the client can accept the given mime type, or > NULL for not accepted. > > - Used for feedback during drag-and-drop. > + For objects of version 2 or older, this request is used by the > + client to give feedback whether the client can receive the given > + mime type, or NULL if none is accepted; the feedback does not > + determine whether drag-and-drop operation succeeds or not. > + > + For objects of version 3 or newer, this request determines the > + final result of the drag-and-drop operation. If the end result > + is that no mime types was accepted, the drag-and-drop operation > + will be cancelled and the corresponding drag source will receive > + wl_data_source.cancelled. Clients may still use this event in > + conjunction with wl_data_source.action for feedback. > </description> > > <arg name="serial" type="uint"/> > @@ -461,9 +471,24 @@ > > <arg name="mime_type" type="string"/> > </event> > + > + <!-- Version 3 additions --> > + > + <request name="finish" since="3"> > + <description summary="the offer will no longer be used"> > + Notifies the compositor that the data offer will no longer be used. > + Upon receiving this request, the compositor will emit > + wl_data_source.drag_finished or wl_data_source.cancelled on the drag > + source client depending on the most recent wl_data_offer.accept and > + wl_data_offer.set_actions requests received from this offer. > + > + It is a client error to perform other requests than > + wl_data_offer.destroy after this one. > + </description> > + </request> > </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 +535,52 @@ > > <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 drag-and-drop operation was performed, but the drop destination > + did not accept any of the mimetypes offered through > + wl_data_source.target. > + - The drag-and-drop operation was performed but didn't happen over a > + surface. > + - The compositor cancelled the drag-and-drop operation (e.g. compositor > + dependent timeouts to avoid stale drag-and-drop transfers).
Another thing to add: - The drag-and-drop was performed and the mimetype negotiation succeded, but the destination did not finish the operation. .. or something, as to what happened if the wl_data_offer.destroy was called without a wl_data_offer.finish. Jonas > + > The client should clean up and destroy this data source. > + > + For objects of version 2 or older, wl_data_source.cancelled will > + only be emitted if the data source was replaced by another data > + source. > </description> > </event> > > + <!-- Version 3 additions --> > + > + <event name="dnd_drop_performed" since="3"> > + <description summary="the drag-and-drop operation physically finished"> > + The user performed the drop action. This event does not indicate > + acceptance, wl_data_source.cancelled may still be emitted afterwards > + if the drop destination does not accept any mimetype. > + > + This event might however not be received if the compositor cancelled > + the drag-and-drop operation before this event could happen. > + > + Note that the data_source may still be used further in the future and > + should not be destroyed here. > + </description> > + </event> > + > + <event name="dnd_finished" since="3"> > + <description summary="the drag-and-drop operation concluded"> > + 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> > > - <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 +722,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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel