cut-paste with VNC on linux - why modify Xvnc server
Wed Feb 12 09:30:01 2003
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
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 --