[RFC v2] Add Primary Selection Protocol Version 1

[Michal Suchanek]

On 18 December 2015 at 18:03, Lyude <cpaul at redhat.com> wrote:
> Signed-off-by: Lyude <cpaul at 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