[RFC v2] Add Primary Selection Protocol Version 1

[Lyude]

On Fri, 2015-12-18 at 21:17 +0100, Michal Suchanek wrote:
> 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.
The reason for this is that we want to be able to allow compositors to easily
bind primary selection pasting to more then just middle clicks, without having
to have some sort of global configuration. The idea is that you just send the
offer before the actual input event, and no matter what the actual input event
is the client can easily tell that it's meant to trigger a primary selection
paste and handle it appropriately.

> 
> Thanks
> 
> Michal
-- 
Cheers,
	Lyude