[RFC wayland-protocols V3] Add Primary Selection Protocol Version 1

[Lyude]

On Thu, 2016-01-07 at 10:37 +0100, Michal Suchanek wrote:
> On 7 January 2016 at 04:42, Jonas Ådahl <jadahl at gmail.com> wrote:
> > On Wed, Jan 06, 2016 at 09:50:36PM -0500, Lyude wrote:
> > > Signed-off-by: Lyude <cpaul at redhat.com>
> > > ---
> > > 
> > > Notes:
> > >                               Changes since V2
> > >     * Bunch of grammatical/wording fixes from whot
> > >     * Addition of wp_primary_selection_offer::end_offers, for marking the
> > > end of a
> > >       list of mime type offers
> > >     * selection_offers are no longer sent before an input event, and are
> > > sent at the
> > >       first opportunity a client has to do a primary selection paste. This
> > > decision
> > >       comes from a discussion with Jasper, where a couple of clients (such
> > > as emacs)
> > >       were brought up that have their own bindings for primary selection
> > > pasting.
> > >       Eventually I will probably work on adding some sort of paste_hint
> > > event to
> > >       this so that the compositor can decide what keybinding triggers a
> > > primary
> > >       selection paste, I agree with Jasper that it would be best to solve
> > > the issue
> > >       of rebinding primary selection pastes after we have the basic
> > > protocol for
> > >       primary selection worked out.
> > 
> > Does this mean that the offer always comes on keyboard focus? Or pointer
> > focus? Or touch focus? Or does it come a user interaction of some kind?
> > And after that it may retrieve the primary selection at any point? Could
> > it not be done as request that is a response to an input event carrying
> > a serial, where the serial can be used to match the request to the
> > triggering user interaction. Or would that break some expectations of
> > the primary selection use case (i.e. retrieve not from a user
> > interaction)?
> 
> The primary selection expectation in X is that an application can
> retrieve it at any time.
I knew I was missing something in this. So, that's basically what it's like now.
A client should be able to expect to get a request the first time something gets
set in the primary selection. So, it is basically the same as X. I'll make sure
to clarify this in the description.

> 
> It has been pointed out that focus is not what it used to be in X and
> and hence is not useful for determining paste ability.
> 
> Also the application should be responsible for determining what action
> (if any) triggers paste and it gives no useful information if the
> paste request is tied to an input event, anyway.
> 
> However, the compositor can and should apply a policy to pastes and
> not send the paste offer to all applications as soon as a selection is
> set.
> 
> One way to do that and preserve the feel of X primary selection is to
> send an offer once an application receives user input (event) after a
> selection was set. That way applications can decide which user action
> triggers a paste using application-specific bindings. As the offer is
> invalidated once new selection is set an application cannot get
> arbitrary pastes from the paste buffer without user action. If desired
> different non-default policy on pastes (event filters) can be applied
> to different applications to accommodate both paste managers that
> should receive paste offer as soon as selection is set and sandboxed
> applications that should not have access to the paste buffer.
> 
> Thanks
> 
> Michal
-- 
Cheers,
	Lyude