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

[Peter Hutterer]

On Thu, Jan 07, 2016 at 01:15:41PM -0500, Lyude wrote:
> 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.

they way I read the current protocol, you're planning on this:
the receiving client gets a selection manager and a selection device, but
there is no way of requesting the selection, you simply get the event
whenever a source sets it. the client needs to hold this until a paste
action happens, handling all cancelled events until then. that seems
inefficient, and potentially leaks information since you know when the
client selected something.

what I'm missing is a request on the selection device that says "gimme the
offer now", followed by the selection_offer event.
unless you're intending to make the get_primary_selection_device() to be
that request, i.e. a client should issue this request in response to
the middle click. That works, I think, but it needs to be documented.

Cheers,
   Peter

> 
> > 
> > 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
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>