:: Ron Goldman <[EMAIL PROTECTED]> :: Hi. I'd like to propose 2 changes to the way that the Linux Xvnc :: server handles cut & paste to the VNC viewer app. I'd appreciate any :: feedback from other VNC users/developers. (Note: This only apply to :: the Linux version, the Mac & Windows versions are fine as is.)
: Jerry McBride <[EMAIL PROTECTED]> : Can you clarify that a bit better? I've been cut-n-pasting on linux : servers and clients without any problems what-so-ever. I assume he's talking aobut the issue that led to autocutsel, namely, that X has at least two different ways to cut-n-paste text. There's the "cutbuffer(s)", and there's the "selection(s)". For various reasons having to do with how the selection is implemented in X, vncviewer/Xnvc only transport the cutbuffer across the link. But most tools nowdays don't use the cutbuffer, so if you drag-select text in (eg) a local netscape, you have some problems trying to paste it into a remote netscape or wish or whatever. If, however, you cut and paste between local and remote xterms, you will have no problems, since xterms take pains to react appropriately to both selection and cut buffer changes. See http://www.uk.research.att.com/vnc/faq.html#q25 That said, my comments would be 1) In my experience, most programs nowdays either handle things via selection, or via some "desktop environment" mechanism outside X proper. From this, I'd prefer to see vncviewer/Xvnc interact with selection better. 2) 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 launched by Xvnc (optional on some switch I imagine), which becomes a client (and hence capable of handling the selection), but operated by commands sent from the Xvnc that launched it. In short, it would operate much as autocutsel does, but with less overhead and more robust. Or put it this way: it'd be a vastly improved autocutsel, and would "be in bed with", and ship with, Xvnc. And the effect would be, it would set both selection and cutbuffer. 3) On the client side, the vncviewer would set both selection and cutbuffer when it gets an incoming selection, an would send a selection when the cursor moved into the remote window and *either* selection or cutbuffer changed (and it should coordinate the two). Now most of these things can be approximated by an autocutsel-like helper, tuned for client or server side use. But the current autocutsel doesn't seem to do the deed completely. It does a good job running on the server side with a windows client, but stumbles a bit if the client also has the cut/sel ambiguity. As a first baby step, I'd make improvements to autocutsel. Then, with the semantics well understood, implement the whole schmear as part of the standard vnc release. More generally, if both vncviewer and vncclient had a hook by which processes could be notified when the cursor is about to go remote, and when it is about to go local, would allow arbitrary policies to be installed for such things. Hmmmm... a wrapper app could do that by detecting the mouse rolling over the boundary of the window (but synchrony between such a detection and the decision to send data remotely is a problem). Wayne Throop [EMAIL PROTECTED] _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] http://www.realvnc.com/mailman/listinfo/vnc-list
