[RFC v2] Add Primary Selection Protocol Version 1

[Peter Hutterer]

On Sun, Jan 03, 2016 at 10:37:47PM -0800, Bill Spitzak wrote:
> On 01/03/2016 10:28 PM, Peter Hutterer wrote:
> 
> >>I really do not like this key assignment being something the compositor is
> >>in charge of. A client may have a very good reason to use middle-click for
> >>something else, yet still want the ability to paste from the selection.
> >
> >this is still possible with the current proposal.
> 
> I think you are talking about the client optionally using the middle click
> for paste or for something else, perhaps depending on where they click. That
> is certainly important.
> 
> As far as I can tell this is purposely preventing clients from using a
> keystroke or shift+click or any other action to trigger a paste from the
> selection. 

yeah, you're right. This could be alleviated by having a request in the
client to say "hey, I'd like to paste" that the compositor again controls
(haven't thought about this in detail though), but this seems something that
we can add when there is a real demand for it.

> That seems wrong to me. Also, despite the comment, it is not
> "identical to that of primary selection pasting in X". X lets the client
> grab the selection buffer at any moment, nothing in the X protocol ties it
> to the middle mouse button.

no but it does it by convention which in the 90% case is the same. having
the buffer accessible by anything at any time is a security issue, moving
the control over to the compositor makes it less so.

> >>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 :)

Cheers,
   Peter