[PATCH wayland 2/2] protocol: Add DnD actions

[Carlos Garnacho]

Hi Michal,

On Mon, Jan 11, 2016 at 11:34 AM, Michal Suchanek <hramrach at gmail.com> wrote:
> On 24 December 2015 at 01:58, Carlos Garnacho <carlosg at gnome.org> wrote:
>
>> @@ -757,6 +883,40 @@
>>        <arg name="id" type="new_id" interface="wl_data_device"/>
>>        <arg name="seat" type="object" interface="wl_seat"/>
>>      </request>
>> +
>> +    <!-- Version 3 additions -->
>> +
>> +    <enum name="dnd_action" bitfield="true" since="3">
>> +      <description summary="drag and drop actions">
>> +        This is a bitmask of the available/preferred actions in a
>> +        drag-and-drop operation.
>> +
>> +        In the compositor, the selected action comes out as a result of
>> +        matching the actions offered by the source and destination sides.
>> +        "action" events with a "none" action will be sent to both source
>> +        and destination if there is no match. All further checks will
>> +        effectively happen on (source actions ∩ destination actions).
>> +
>> +        In addition, compositors may also pick different actions in
>> +        reaction to key modifiers being pressed, one common ground that
>> +        has been present in major toolkits (and the behavior recommended
>> +        for compositors) is:
>> +
>> +        - If no modifiers are pressed, the first match (in bit order)
>> +          will be used.
>> +        - Pressing Shift selects "move", if enabled in the mask.
>> +        - Pressing Control selects "copy", if enabled in the mask.
>> +
>> +        Behavior beyond that is considered implementation-dependent.
>> +        Compositors may for example bind other modifiers (like Alt/Meta)
>> +        or drags initiated with other buttons than BTN_LEFT to specific
>> +        actions (e.g. "ask").
>> +      </description>
>> +      <entry name="none" value="0"/>
>> +      <entry name="copy" value="1"/>
>> +      <entry name="move" value="2"/>
>> +      <entry name="ask" value="4"/>
>> +    </enum>
>>    </interface>
>>
>
> Hello,
>
> how do you go about implementing those implementation-specific actions?

One detail I think you've missed: it's compositors who decide the
action. Clients on both sides will only receive wl_data_source events
on the source side and wl_data_device/wl_data_offer events on the
destination side.

>
> Let's say I have a client which id DnD source in an operation and
> wants to paste text without formatting when ALT is pressed. It can
> technically change the offered mime-types or perform a different
> object conversion when sending the data if it learns the key is down.
> Will it learn about the key state?

It can't technically do that, wl_data_source.offer is cummulative,
there's no wl_data_source.reset nor somesuch. There's also no way then
to have the drag destination know when/whether the mimetypes list is
definitive. And besides, it's the destination which chooses the most
suitable mimetype through wl_data_offer.accept. This sounds like the
opposite than the current protocol in git offers.

Also, why should the drag source choose whether plain/formatted text
is transferred? it'd be the drag destination which can actually tell
if it can manage either. Your usecase actually doesn't stand if you
s/without/with/, what should weston-terminal do if the source enforces
formatted text?

Third, this patch is about DnD actions, mimetypes are just tangential,
besides you having to .accept one for the transfer to succeed.
Mimetypes are exclusively about the destination choosing the most
suitable/lossless/etc format.

>
> Another example would be a client that is DnD destination and wants to
> paste only text style when the user holds the 10th mouse button or 5th
> touchscreen softbutton when the object is dropped. Will it get to know
> that the event happened? It will probably want to reject move action
> in this case since the object is not fully transferred. There is no
> mime type for text style there is no way to transfer it other than
> transferring whole formatted text clip and then trashing the text (and
> it's going to be hairy if the text is not formatted uniformly).

What is "text style"? Why must be "move" rejected? Why must this mode
be chosen during DnD instead of through a different mimetype on
.start_drag, or destination-side UI through an "ask" action?

How do you know if the user has a 10th mouse button or a softbutton?
How do you fallback if he doesn't? as for the softbutton case the
compositor seems again in a better situation to know so (as it is the
case with a11y considerations).

I'm really not sure which model you're pushing for, do you want the
drag source or destination to handle buttons/modifiers? both? have you
considered compatibility with Xdnd? This all was already discussed in
ealier threads with no clear gains on either other option. And being
at v9 of this patch, I'm not personally keen on modifying such
fundamental aspect.

Cheers,
  Carlos