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

[Michal Suchanek]

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.

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