<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 6, 2016 at 7:42 PM, Jonas Ådahl <span dir="ltr"><<a href="mailto:jadahl@gmail.com" target="_blank">jadahl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>Does this mean that the offer always comes on keyboard focus? Or pointer<br>
focus? Or touch focus? Or does it come a user interaction of some kind?<br></blockquote><div><br></div><div>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.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And after that it may retrieve the primary selection at any point?</blockquote><div><br></div><div>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".<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Could<br>
it not be done as request that is a response to an input event carrying<br>
a serial, where the serial can be used to match the request to the<br>
triggering user interaction. Or would that break some expectations of<br>
the primary selection use case (i.e. retrieve not from a user<br>
interaction)?<br></blockquote><div><br></div><div>I think that would make it impossible to emulate the X11 interface. Also it adds round trips.<br><br></div><div>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.<br><br></div><div>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.<br><br></div></div><br></div></div>