[PATCH] selection: send selection events to all connected clients

[Pekka Paalanen]

On Mon, 15 Apr 2013 09:08:44 -0400
Yichao Yu <yyc1992 at gmail.com> wrote:

> On Mon, Apr 15, 2013 at 5:00 AM, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> > On Mon, 15 Apr 2013 04:03:43 -0400
> > Yichao Yu <yyc1992 at gmail.com> wrote:
> >
> >> On Mon, Apr 15, 2013 at 3:45 AM, Pekka Paalanen
> >> <ppaalanen at gmail.com> wrote:
> >> > On Sun, 14 Apr 2013 21:45:37 -0400
> >> > Yichao Yu <yyc1992 at gmail.com> wrote:
> >> >
> >> >> On Sun, Apr 14, 2013 at 9:33 PM, Matthias Clasen
> >> >> <matthias.clasen at gmail.com> wrote:
> >> >> > On Fri, Apr 12, 2013 at 1:33 PM, Yichao Yu <yyc1992 at gmail.com>
> >> >> > wrote:
> >> >> >> A lot of useful features require clipboard access and
> >> >> >> monitoring without having a keyboard focus, e.g. clipboard
> >> >> >> action (klipper[1] and some download agents), command line
> >> >> >> access (IPython's %paste magic). This patch sends out
> >> >> >> selection events to all clients when the selection owner
> >> >> >> changes no matter whether the client has a focus or not in
> >> >> >> order to support these features.
> >> >> >
> >> >> > Clipboard managers are pretty specialized clients, and you
> >> >> > usually only run at most one of them in your session - why
> >> >> > confuse all other clients with the extra events ?
> >> >>
> >> >> Actually all client may want to know the clipboard content even
> >> >> when it doesn't have focus. And clipboard monitoring doesn't
> >> >> means clipboard manager. It is also used by many download
> >> >> agents as what I have said.

...

> >> > Allowing command line utilities the access to clipboard contents
> >> > (or to take screenshots, equivalently), is a problem. Enabling
> >> > them enables all spy programs, too. I'm not sure we can both
> >> > enable them and stay
> >> > secure, it seems to be an either-or for a user to choose. But we
> >> > *can* design a protocol extension to allow enabling them at
> >> > runtime, and leave the choice of actually using it for the server
> >> > (controlled by the user). How the control works in the GUI is not
> >> > interesting. The protocol extension is interesting.
> >> >
> >> > An optional protocol extension must be the starting point for any
> >> > proposals like this one. Let's keep the system secure by default,
> >> > but
> >> > allow workarounds if needed. That is why you should not modify
> >> > the core protocol but introduce a new extension, that is
> >> > optional, and preferrably also handles dynamic security policy
> >> > changes runtime (i.e. doing a currently forbidden action would
> >> > not be fatal to the client).
> >> >
> >> > It is also useful to not specify any particular ways or reasons
> >> > to enable or disable these optional extension in the
> >> > specification, as long as they can be switched dynamically. This
> >> > allows other people to come up with and implement nice ways to
> >> > toggle them, perhaps even as per-client basis.
> >> >
> >> > In other words, if it is still unclear, I am proposing that you
> >> > should create a protocol extension, an interface, that will
> >> > allow a client to ask for the current clipboard contents. The
> >> > server may accept or refuse. You can also add content change
> >> > events, and the server may or may not send them, depending
> >> > whether it currently allows getting the clipboard content. This
> >> > extension would cater for all random clients wanting to get the
> >> > clipboard content at arbitrary times, like command line
> >> > utilities. Clipboard managers may require a different interface,
> >> > depending on their needs. Do not put random clients and a
> >> > clipboard manager into the same bucket, like we already separate
> >> > random clients and a screenshooter client.
> >> >
> >> > Or if you can already do the above with the existing protocol,
> >> > you are welcome to propose that, but keep in mind that it has to
> >> > be secure by default, and you may not break the protocol or ABI.
> >
> > What's wrong with this proposal?
> >
> > I do not believe your patch will get through, so you will have to
> > revise it anyway. I was just trying to be helpful, and suggest
> > something that might be acceptable, since you clearly do not see the
> > security implications, or the technical implications of waking up
> > every single client every time the selection changes.
> >
> 
> Clipboard manager (or all other programs that need clipboard
> monitoring) may be special, but I don't see why it is necessary to
> break every single toolkits' api by don't allowing them to get
> clipboard content without a focus. There is no way to do it (get
> clipboard at any time) without breaking the current interface and
> without sending out every selection changes.

Alright. I'm not too familiar with toolkits, so could you explain why
toolkits need to access the selection at arbitrary times (specifically
while unfocused), instead of only as a response to direct user input
(which in all relevant cases assigns the focus first)?

And this question is not about clipboard managers, this is about normal
applications. Clipboard managers are a totally different case, as has
been said in this thread several times.

I would tend to claim, that no toolkit use case in normal applications
will be broken by not being able to get the selection at arbitrary
times. Can you provide a counter-example?

Command line utilities for fetching the current selection would not
work, but are we talking about them anyway? If we talk about them, then
we need an optional protocol extension.

I do not see why there could not be a way to get the selection at any
time by introducing a new protocol extension, like I suggested,
without breaking existing interfaces. From toolkit or application point
of view, it does not really differ from the core interface for
selections. It would just be another Wayland specific bit to support in
the clients that want to receive the selection. There would be no
impact to clients setting or offering a selection.

And why do I insist? Security and isolation. We want clients to
know about each other as little as possible, and spy on others'
data even less. Because I believe this is according to the Wayland
design principles. I also have not yet heard a compelling reason why
the existing protocol does not work as is for normal applications.


Thanks,
pq