cut-paste with VNC on linux - why modify Xvnc server

[Ron Goldman]

On Mon, 10 Feb 2003 13:18:03, Wayne Throop wrote:
> The problem with selection is, on the server side, you need
> to be a client to manage a selection, so it's a bit odd to
> make the server it's own client.   Possible to do, but simpler
> (and IMO an adequate solution) would be to have a helper process...

Right, normally the X server just acts as an intermediary and leaves it 
to the clients to manage the selection, including converting it from 
one format to another. So my first thought was also to just improve 
autocutsel. However that approach doesn't seem feasible since X does 
not contain any mechanism to notify a client that the selection 
(primary or clipboard) has changed --- the helper app would need to 
poll periodically as autocutsel does now.

Your idea of detecting when the user moves their cursor into or out of 
the VNC viewer client window is the ideal solution. At that point the 
remote client would either request the current selection from the 
server (cursor moving out of viewer window) or send over the remote 
selection (cursor moving into viewer window). However this requires 
modifying the RFB protocol to add a new client-server message to 
request the current selection. That seems a bit much and would break 
compatibility with current viewers.

That leaves just modifying the Xvnc server itself. Now in some sense 
the whole point of the server is to act as a proxy for the remote 
viewer, so having the server act for the viewer in this case seems 
reasonable. The main concern in having the server mimic a client is 
that it can do so directly in one short operation that won't take much 
time or involve a complicated exchange of messages with other client 
apps. And indeed that can be done in this case.

The way selection works in X is for a client to notify the server when 
it owns the selection and the server updates its internal state to 
remember which client is the new owner --- the old is sent a message 
saying it no longer is the owner. Then when some other client wants to 
paste the selection it sends a message to the server & the server 
forwards the request on to the client that owns the selection. The 
owner then converts the selection to the requested format, sends 
messages to the server to write the selection value to the requesting 
window (via a property) and then sends a message to the requester 
saying that the value is available. For complicated cases this can 
involve exchanging several messages between the selection owner and the 
requester.

For Xvnc to act as the selection owner, the server just updates its 
internal state when it receives a new selection from the VNC viewer. 
Then when any client app requests the selection, the server can 
internally copy the text to the appropriate window's property and send 
the message to the requester that the value is available. The potential 
complicated cases do not apply, so one message is sufficient.

Going in the other direction the server currently detects when any 
client app changes the value of the cut buffer (a property of the 
default window) and when that happens the new value is sent over the 
wire to the remote VNC viewer. Instead of using a helper app like 
autocutsel to detect changes to the primary selection and then update 
the cut buffer, a more direct solution is the following: When some 
random app tells the server that it is the new selection owner, the 
server can send that client app a message asking it to copy its text 
value to the cut buffer property, which will then be sent to the VNC 
viewer. (And for my proposal to have VNC pass the clipboard instead of 
the primary selection, a different internal property can be used so as 
to not confuse the clipboard's value with the cut buffer's.)

The required changes to the Xvnc code are surprisingly minimal: two 
added tests to detect client requests to set/get the selection & a 
small routine to send the message notifying the requesting client that 
the selection value has been transferred to it.

So have I maybe convinced you that my proposed solution is reasonably 
clean and not a kludge?

-- Ron --