[RFC v2] Add Primary Selection Protocol Version 1

[Bill Spitzak]

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.