On 18 December 2015 at 18:03, Lyude <cp...@redhat.com> wrote: > Signed-off-by: Lyude <cp...@redhat.com>
> + <event name="selection_offer"> > + <description summary="primary selection buffer is ready for reading"> > + Sent when the client has permission to read from the primary > selection > + buffer. > + > + This event is sent whenever the client receives a middle click, and > will > + be received by the client before the actual middle click event. While > + the compositor is free to bind this event to another input event > (such > + as a keyboard shortcut), the client should always treat pastes from > the > + primary selection as middle clicks. This is to ensure the behavior is > + identical to that of primary selection pasting in X. > + > + It is up to the client to decide whether or not it is appropriate to > + read from the primary buffer and paste it's contents. > + </description> > + <arg name="offer" type="new_id" > interface="zwp_primary_selection_offer_v1"/> > + </event> > + Why this? Is this an artifact of cut&paste from DnD spec? Drop is something initiated by dropping an object from the outside but paste is something the application initiates by itself. The primary selection is something that sits there all the time ready to be pasted unlike dropped objects which appear and disappear momentarily. It is customary in current desktop that paste happens on middle click but that is something that is just configured in every toolkit separately to work the same across whole desktop. The application itself should decide if and on what event it tries to pull the primary selection content. Note also that there are cut buffer managers that just pull and store the primary buffer content every time it is set so if X compatibility is desired setting the paste buffer should generate an event. Thanks Michal _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
