<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 5, 2016 at 7:47 AM, Michal Suchanek <span dir="ltr"><<a href="mailto:hramrach@gmail.com" target="_blank">hramrach@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div><div class="h5">
> Maybe it should only send the newid if the selection has changed. The client<br>
> can keep the old object around until it is destroyed, even if it gets many<br>
> clicks.<br>
><br>
> ie. when the selection changes, any old offers get the destroyed event. But<br>
> clients do not get the new offer until they get another middle click. If the<br>
> user clicks many times only one offer proxy is created.<br>
><br>
> The overhead may not be so minimal in creating/destroying local objects in<br>
> some languages such as Python, so it does seem nice to avoid this. A bigger<br>
> concern is that if more events are decided to be "pasteable" by the<br>
> compostior, it will have to send the offer even more times (imagine if it is<br>
> decided that any keystroke can paste). This rule means it only has to send<br>
> it before the first such event.<br>
<br>
</div></div>Actually, this sounds reasonable.<br>
<br>
When there is a selection set and an application receives any input<br>
event it will also receive a paste offer. It can then act on that<br>
offer any time until a new selection is set. It does need  any new<br>
offer until new selection is set.<br>
<br>
When concerned about pasting into the wrong application the user can<br>
unmap/minimize/whatever the application window so it cannot receive<br>
input events.<br></blockquote><div><br></div><div>Actually with this design, a user can be certain that no other app can see the selected text unless they actually click the middle mouse in that app after making the selection. Even with the more extreme versions I think will eventually appear, the app probably will not see the selection unless they type a key or click in it. This may make it safe to select passwords and other sensitive data.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There is only slight problem with paste buffer managers and download<br>
managers which try to watch for paste buffer changes in the background<br>
without receiving any input. This can be probably amended by setting<br>
different paste policies (filters for events that allow access to the<br>
paste buffer) for different applications.<br></blockquote><div><br></div><div>Yea it would prevent that. Maybe those could require special privledges, and they will get the event with the offer on all changes. <br><br></div></div></div></div>