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

[Yichao Yu]

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.

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

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

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

> 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