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

[Bill Spitzak]

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.

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.