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

[Bill Spitzak]

On Wed, Jan 6, 2016 at 7:42 PM, Jonas Ådahl <jadahl at gmail.com> wrote:

>
> 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?
>

I think the last one is the intention here. The offer will come just before
an event that the compositor consideres a possible "paste event". The
original proposal was for this to be limited to middle mouse down, but it
sounds like it will be on all button and key down events. I now think the
idea is good, it prevents a client from passively watching the contents of
the selection, and may mean it is safe to select passwords and other
sensitive information. I also will contradict what I said before, it seems
good to not tie this to focus, so that simply moving the mouse does not
give clients the ability to peek at the selection.

And after that it may retrieve the primary selection at any point?


Yes, until the selection is changed. At that point it will get a destroyed
event on the offer, but it won't get another offer until the next "paste
event".

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

I think that would make it impossible to emulate the X11 interface. Also it
adds round trips.

X11 just has a "selection was changed" event, and the ability to read the
selection. I think this can be mapped from this api without giving the X11
clients any more ability to peek at the selection, by having the
destruction of the offer act as though the selection was changed to an
empty string, and the new offer act as though the selection was changed yet
again. So a middle-mouse click will give an X11 client a selection changed
event followed immediately by the mouse click.

Something I do realize is necessary: the client making the selection needs
an indication that another client has made a selection. This is so it can
redraw highlighting to show the fact that it no longer has the selection
(I'm not saying this is required, but it is a behavior that should be
possible). Right now this sends destruct events to the clients that got the
offer, but I don't think anything is sent to the source client. I think
this needs to be another event on the primary_selection_device.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20160107/d43658a8/attachment.html>