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

[Pekka Paalanen]

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

> On Mon, Apr 15, 2013 at 9:44 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > 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)?
> 
> What I mean is it breaks the api, the api provided by toolkits to
> access clipboard will not work at any time, a constraint that doesn't
> exist in any other systems.

Is that really used so much, that it is a problem, or do all use
cases implicitly fall to the focused window case?
Is there a problem with simply returning "no selection" in the
toolkit API, if a client accidentally calls it without focus?

> > 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?
> 
> Well, if you really want a example, than it can be a pastebin
> application using statusnotify and dbusmenu protocol which get input
> from the user through dbus without any focus and need to get the
> clipboard content and uploaded when requested.

Cool, what is the app's name? Real use cases are what we need for
properly solving problems like this. As I've obviously never used
one, would nice to try and understand how it works (in X, of
course).

> > Command line utilities for fetching the current selection would not
> > work, but are we talking about them anyway? If we talk about them, then
> 
> Yes, at least I am.

Ok, so we have three different cases, all with different needs, and
therefore most likely different interfaces:
- clipboard managers; privileged, authentication controlled
  interface, likely private before standardization
- windowless clients (command line utilities); user toggled feature
  and a security risk, broadcasted offers to subscribers
- normal applications; what we have right now in the protocol

> > 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
> 
> If there is another protocol to get clipboard content at any time, I
> am wondering if the current one is still useful.

The current one will be used by all normal applications, because
the broadcast version (windowless clients) is not always available
or usable. Also, we want the broadcast version to be opt-in, so
that clients that do not opt-in, can receive selection via the
normal mechanism.

Users of the broadcast version should be very few, I believe.

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