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

[Pekka Paalanen]

On Mon, 15 Apr 2013 12:32:30 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> Pekka Vuorela wrote:
> 
> >> 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.
> > 
> > Breaks how? On Qt you get clipboard by instantiating QClipboard
> > which takes mode (global clipboard, selection) on constructor.
> > There's even bool supportsSelection() to check if the environment
> > supports such. Gtk+ similarly appears to have a mode on
> > instantiation phase, and even assumes getting content might block
> > because of being fetched from the environment.
> 
> I think his complaint is that a Qt application, at any time, can call 
> this code (there are probably variations but this is what our
> software does):
> 
>   QString x = QApplication.clipboard()->text(QClipboard::clipboard);
> 
> or (to preserve UTF-8):
> 
>   bytes = QApplication.clipboard()->mimeData().data("text/plain");
> 
> A client can call this at *any* time, therefore technically it needs
> to get the clipboard at any time.
> 
> However I think any real client will only do this in response to an 
> event that allows the clipboard api to work.
> 
> There is the problem that some clients probably call this many times,
> so to fix that Qt will have to keep returning the previous value
> after it is able to retrieve the clipboard value. It cannot return
> "no data" the second time or when focus is lost.
> 
> I do think a single addition which is a one-shot "clipboard change" 
> request, would be useful for clipboard monitoring programs. It would 
> send an event on the next change to the clipboard (or immediately if
> the clipboard has changed since last read by this client) and after
> that event the setup is exactly the same as when paste events are
> done.

I would agree. We might not even need a new clipboard change event, if
the existing protocol is sufficient (which I'm not certain about for
all possible cases). We just need a mechanism to control who gets the
change events. This control mechanism or interfaces should be
privileged, whatever it will be.

> If there are security worries I suppose it could be privileged, but I 
> really think a nefarious client could easily get the clipboard
> contents as soon as the mouse points at a window it owns.

If there is a window to point to, it becomes a little harder to do it in
secret. If we require keyboard focus instead of just pointer focus for
the normal case, the user would have to accidentally focus the spy
window, which is even harder to do in secret.

It's not waterproof, but makes it again a little hard to abuse.


Thanks,
pq