Hi Michal, On Mon, Jan 11, 2016 at 11:34 AM, Michal Suchanek <[email protected]> wrote: > On 24 December 2015 at 01:58, Carlos Garnacho <[email protected]> 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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
