[PATCH wayland] protocol: Add DnD actions
Bill Spitzak
spitzak at gmail.com
Thu Jun 11 14:05:38 PDT 2015
I think everybody is waiting for an explanation as to why one of the
clients cannot choose the action, and instead the compositor does it.
You are defining a function f(S,D,M) that takes three inputs and returns a
selected action. The three inputs are the set of actions from the source
(S), the set of actions from the destination (D), and the modifiers (M).
The design you are proposing is:
Source sends S to compositor
Dest sends D to compositor
Compositor knows M and performs A=f(S,D,M)
Compositor sends A to source
Compositor sends D to dest
What I propose is:
Source sends S to compositor
Compositor sends S to dest
Compositor sends M to dest (probably by giving it keyboard focus)
Dest knows D and performs A=f(S,D,M)
Dest sends A to compositor
Compositor sends A to source
I believe this is what most everybody here is proposing, though I think
some are considering the source doing the work instead.
I really dislike the idea that the definition of f(S,D,M) is in the
compositor. It should be in the clients.
Can you please give an example of why you think this is absolutely
necessary. There are some vague indications that you feel this is required
to emulate XDND but I really don't see it, as any necessary logic can be in
the XWayland "client" (ie what is between an X client and the Wayland
compositor). XDND may dictate what parts are done by the source and dest
but I cannot see any reason it could dictate that the compositor has to do
it.
On Tue, Jun 9, 2015 at 9:55 AM, Carlos Garnacho <carlosg at gnome.org> wrote:
> These 2 requests have been added:
>
> - wl_data_source.set_actions: Notifies the compositor of the available
> actions on the data source.
> - wl_data_offer.set_actions: Notifies the compositor of the available
> actions on the destination side, plus the preferred action.
>
> Out of the data from these requests, the compositor can determine the
> action
> both parts agree on (and let the user play a role through eg. keyboard
> modifiers). The chosen option will be notified to both parties
> through the following two requests:
>
> - wl_data_source.action
> - wl_data_offer.action
>
> In addition, the destination side can peek the source side actions through
> wl_data_offer.source_actions.
>
> In order to complete the information about the DnD progress on the source
> side, the following 2 wl_data_source events have been added too:
>
> - wl_data_source.drop_performed: Received when the operation physically
> finishes (eg. the button is released), this can be used to undo any
> state resulting from the initial button press.
> - wl_data_source.drag_finished: Received when the destination side
> destroys the wl_data_offer, at which point the source can just ditch
> all related data as well.
>
> As a result of all of this, the semantics of wl_data_source.cancelled
> have been defined better, so it is clearer when this needs to be emitted.
>
> Compared to the XDND protocol, there is one notable change: XDND lets the
> source suggest an action, whereas wl_data_device lets the destination
> prefer a given action. The difference is subtle here, it comes off as
> convenience because it is the drag destination which receives the motion
> events (unlike in X) and can perform action updates.
>
> The drag destination seems also in a better position to update the
> preferred action based on things like the data being transferred, the
> place being dropped, and whether the drag is client-local.
>
> Roughly based on previous work by Giulio Camuffo <giuliocamuffo at gmail.com>
>
> Changes since v2:
> - Renamed notify_actions to set_actions on both sides, seems more
> consistent
> with the rest of the protocol.
> - Spelled out better which events may be triggered on the compositor side
> by the requests, the circumstances in which events are emitted, and
> what are events useful for in clients.
> - Defined a minimal common ground wrt compositor-side action picking and
> keybindings.
> - Acknowledge the possibility of compositor/toolkit defined actions, even
> though none are used at the moment.
> Changes since v1:
> - Added wl_data_offer.source_actions to let know of the actions offered
> by a data source.
> - Renamed wl_data_source.finished to "drag_finished" for clarity
> - Improved wording as suggested by Bryce
>
> Signed-off-by: Carlos Garnacho <carlosg at gnome.org>
> ---
> protocol/wayland.xml | 161
> +++++++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 155 insertions(+), 6 deletions(-)
>
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index f52677f..c3b8ae4 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
> @@ -461,9 +461,55 @@
>
> <arg name="mime_type" type="string"/>
> </event>
> +
> + <!-- Version 3 additions -->
> +
> + <event name="source_actions" since="3">
> + <description summary="notify the source-side available actions">
> + This event indicates the actions offered by the data source. It
> + will be sent right after data_device.enter, or anytime the source
> + side changes its offered actions through data_source.set_actions.
> + </description>
> + <arg name="source_actions" type="uint"/>
> + </event>
> +
> + <event name="action" since="3">
> + <description summary="notify the selected action">
> + This event indicates the action selected by the compositor after
> + matching the source/destination side actions. Only one action (or
> + none) will be offered here.
> +
> + This event can be emitted multiple times during the drag-and-drop
> + operation, mainly in response to source side changes (through
> + data_source.set_actions), destination side changes (through
> + data_offer.set_actions), and as pointer enters/leaves surfaces.
> +
> + Compositors may also change the selected action on the fly, mainly
> + in response to keyboard modifier changes during the drag-and-drop
> + operation.
> +
> + The most recent action received is always the valid one.
> + </description>
> + <arg name="dnd_action" type="uint"/>
> + </event>
> +
> + <request name="set_actions" since="3">
> + <description summary="set the available/preferred drag-and-drop
> actions">
> + Sets the actions that the destination side client supports for
> + this operation. This request may trigger the emission of
> + data_source.action and data_offer.action events if the compositor
> + needs changing the selected action.
> +
> + This request can be called multiple times throughout the
> + drag-and-drop operation, typically in response to
> data_device.enter
> + or data_device.motion events.
> + </description>
> + <arg name="dnd_actions" type="uint"/>
> + <arg name="preferred_action" type="uint"/>
> + </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 +556,77 @@
>
> <event name="cancelled">
> <description summary="selection was cancelled">
> - This data source has been replaced by another data source.
> - The client should clean up and destroy this 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 the drop destination did not
> + select any action present in the mask offered through
> + data_source.action.
> +
> + The client should clean up and destroy this data source.
> </description>
> </event>
>
> + <!-- Version 3 additions -->
> +
> + <event name="action" since="3">
> + <description summary="notify the selected action">
> + This event indicates the action selected by the compositor after
> + matching the source/destination side actions. Only one action (or
> + none) will be offered here.
> +
> + This event can be emitted multiple times during the drag-and-drop
> + operation, mainly in response to source side changes (through
> + data_source.set_actions), destination side changes (through
> + data_offer.set_actions), and as pointer enters/leaves surfaces.
> +
> + Compositors may also change the selected action on the fly, mainly
> + in response to keyboard modifier changes during the drag-and-drop
> + operation.
> +
> + The most recent action received is always the valid one.
> +
> + Clients can trigger cursor surface changes from this point, so
> + they reflect the current action.
> + </description>
> + <arg name="dnd_action" type="uint"/>
> + </event>
> +
> + <request name="set_actions" since="3">
> + <description summary="set the available drag-and-drop actions">
> + Sets the actions that the source side client supports for this
> + operation. This request may trigger a data_source.action event and
> + data_offer.action events if the compositor needs changing the
> + selected action.
> + </description>
> + <arg name="dnd_actions" type="uint"/>
> + </request>
> +
> + <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 (either
> + immediately, or in a delayed manner on "ask" actions) and should
> + not be destroyed here.
> + </description>
> + </event>
> +
> + <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.
> +
> + Clients can also trigger the deletion of source-side data on
> + "move" drag-and-drop operations.
> + </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 +768,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
> @@ -682,6 +791,46 @@
> <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" since="3">
> + <description summary="drag and drop actions">
> + This is a bitmask of the available/preferred actions in a
> + drag-and-drop operation.
> +
> + The current reserved ranges are:
> +
> + 0x0000 - 0x00FF: Reserved for the wayland core protocol.
> + 0x01FF - 0xFFFF: Reserved for future toolkit-specific use. Slots
> + may be reserved.
> +
> + 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 & dest_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 (eg. "ask", or the next match after move/copy).
> + </description>
> + <entry name="none" value="0"/>
> + <entry name="copy" value="1"/>
> + <entry name="move" value="2"/>
> + <entry name="ask" value="4"/>
> + </enum>
> </interface>
>
> <interface name="wl_shell" version="1">
> --
> 2.4.2
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150611/679ad202/attachment-0001.html>
More information about the wayland-devel
mailing list