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

[Carlos Garnacho]

Hey :),

On Tue, Nov 3, 2015 at 1:36 AM, Jonas Ådahl <jadahl at gmail.com> wrote:
> On Fri, Oct 30, 2015 at 09:55:37PM +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_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 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 <carlosg at gnome.org>
>> ---
>>  protocol/wayland.xml | 47 +++++++++++++++++++++++++++++++++++++++++------
>>  1 file changed, 41 insertions(+), 6 deletions(-)
>>
>> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
>> index 59819e9..477ef55 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,9 @@
>>       Indicate that the client can accept the given mime type, or
>>       NULL for not accepted.
>>
>> -     Used for feedback during drag-and-drop.
>> +     This request mandates the final result of the drag-and-drop
>> +     operation. If the end result is that no mimetype is accepted,
>> +     the drag source will receive drag_source.cancelled.
>
> This adds requirements to how to use .accept, but doesn't specify
> whether they are only added for version >= 3 or not, making this part
> change the previous versions of the protocol.
>
> If we want to change the previous versions, we need to be sure the new
> behavior was the actual intended behavior (as for when we changed
> wl_subsurface's commit behaviour), and make that change as a separate
> commit with its own explanation.

Right, IMO the gist of the behavioral change is the emission of
data_source.cancelled on DnD altogether. The cancelled event is
currently documented as "This data source has been replaced by another
data source", so weston indeed does emit that for the clipboard, but
never for DnD sources.

Even though that doc description doesn't make a lot of sense for a DnD
source, it's indeed not too conclusive about which sources it does
apply to. I guess that clients relying on this specific behavior from
weston might crash if they're unprepared for anything else than
clipboard sources there, but otoh this leaves the source unable to
know anything at all about the dnd state after start_drag.

>
> Otherwise we need to make it clear that the new requirements of the
> "accept" request is only relevant for version >= 3.

That's understandably a safer path, I consider the other additions
also essential for functional DnD, so older clients would remain with
quirks even with the behavioral change. I'm adding these blurbs to
.accept and .cancelled:

"Prior to version 3, data_source.accept was only considered for
client-side feedback, compositors wishing to preserve compatibility
with older versions should not emit data_source.cancelled as result of
a NULL target in those clients."

"Prior to version 3, data_source.cancelled was documented as being
emitted in situations that made only sense on clipboard sources,
compositors wishing to preserve compatibility with older versions
should only emit this signal for clipboard sources in those clients."

>
> Other than this, either with the "dnd_performed" renamed to
> "dnd_drop_performed" or not, this one is

Yeah, I think I'll squash that change.

> Reviewed-by: Jonas Ådahl <jadahl at gmail.com>

Thanks!

  Carlos