[RFC v2] Add Primary Selection Protocol Version 1

[Michal Suchanek]

Hello,

On 5 January 2016 at 07:04, Bill Spitzak <spitzak at gmail.com> wrote:
> On 01/04/2016 08:33 PM, Peter Hutterer wrote:
>
>>>>> Also it seems like you will send this on *every* middle click. Some
>>>>> clients
>>>>> require clicking the middle button a lot without pasting (it is very
>>>>> common
>>>>> to use it as a pan control in 2D/3D).
>>>
>>>
>>>> in the normal use-case you will get a lot more focus changes than middle
>>>> clicks.
>>>
>>>
>>> Not if middle-click is used for panning. That's why I mentioned it.
>>>
>>> You are correct though that it is probably irrelevant. Though I am a bit
>>> concerned that this event includes an object with a new id, and all the
>>> necessary work on both the compositor and client to track it.
>>
>>
>> one of the big benefits that input related stuff has is that you don't
>> need
>> to care too much about resources. yes, this protocol involves creating and
>> destroying objects on every middle click. Compared to the textures you
>> just
>> had to load to display the web browser, this is peanuts. Crushed into very
>> small pieces :)
>
>
> Maybe it should only send the newid if the selection has changed. The client
> can keep the old object around until it is destroyed, even if it gets many
> clicks.
>
> ie. when the selection changes, any old offers get the destroyed event. But
> clients do not get the new offer until they get another middle click. If the
> user clicks many times only one offer proxy is created.
>
> The overhead may not be so minimal in creating/destroying local objects in
> some languages such as Python, so it does seem nice to avoid this. A bigger
> concern is that if more events are decided to be "pasteable" by the
> compostior, it will have to send the offer even more times (imagine if it is
> decided that any keystroke can paste). This rule means it only has to send
> it before the first such event.

Actually, this sounds reasonable.

When there is a selection set and an application receives any input
event it will also receive a paste offer. It can then act on that
offer any time until a new selection is set. It does need  any new
offer until new selection is set.

When concerned about pasting into the wrong application the user can
unmap/minimize/whatever the application window so it cannot receive
input events.

There is only slight problem with paste buffer managers and download
managers which try to watch for paste buffer changes in the background
without receiving any input. This can be probably amended by setting
different paste policies (filters for events that allow access to the
paste buffer) for different applications.

Thanks

Michal