On Mon, 10 Feb 2003 13:18:03, Wayne Throop wrote:
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.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...
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 --
_______________________________________________
VNC-List mailing list
[EMAIL PROTECTED]
http://www.realvnc.com/mailman/listinfo/vnc-list
