[RFC v2] Add Primary Selection Protocol Version 1

[Bill Spitzak]

On Tue, Jan 5, 2016 at 7:47 AM, Michal Suchanek <hramrach at gmail.com> wrote:

>
> > 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.
>
> Actually, this sounds reasonable.
>
> When there is a selection set and an application receives any input
> event it will also receive a paste offer. It can then act on that
> offer any time until a new selection is set. It does need  any new
> offer until new selection is set.
>
> When concerned about pasting into the wrong application the user can
> unmap/minimize/whatever the application window so it cannot receive
> input events.
>

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.


> There is only slight problem with paste buffer managers and download
> managers which try to watch for paste buffer changes in the background
> without receiving any input. This can be probably amended by setting
> different paste policies (filters for events that allow access to the
> paste buffer) for different applications.
>

Yea it would prevent that. Maybe those could require special privledges,
and they will get the event with the offer on all changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20160105/cb94e00f/attachment-0001.html>