cut/paste issues in VNC

[Wayne Throop]

:: "W. Brian Blevins" <brian "at" tridia.com>
:: I agree that it seems like Xvnc should support, meaning read and
:: write to, both the cutbuffer and selection mechanisms.  The strange
:: thing is that from the source code it already *appears* to do this. 
:: Unfortunately, I have not had the time to track this down thoroughly. 
:: Maybe there was some unexpected side-effect from the original
:: implementation and it had to be turned back off. 

: Jeff Boerio <boerio "at" ichips.intel.com>
: Actually, it appears to work ...  most of the time.  Quicking
: vncviewer and restarting it appears to work around the problem. 

Hmmm.  But "both working" is a little ambiguous, especially in the MS
case.  I think only the X vncviewer knows about X's notion of "primary
selection".  So one problem may be that with Xvnc and a WinDoze
vncviewer, only the cutbuffer gets set when attempting to cut from the
WinDoze desktop and paste into an X app.  As I said, some X apps are
completely blind to the cut buffer.  Some aren't; but some are.  This is
what the original symptom description most sounded like. 

Now, looking at the behaviors, it's fairly clear that Xvnc and the X
version of vncviewer *try* to coordinate both, as best they can.
For example, when xterm has the primary selection on the outer
window, moving the cursor into the inner window revokes the inner
primary selection, allowing any inner xterm to paste the cutbuffer instead
(since xterm tries to use both).  So, cut/paste in both directions
seems to work between xterms fairly well.  And between some other
Athena X apps.  But netscape, tcl/tk, and many others, have problems,
and you have to manually copy between selection and cutbuffer to
cut/paste between (say) an inner and an outer tk-based editor.

In short, "it appears to work ... most of the time".  Just so.

Note: even with X server and X viewer, and supposing both know about the
cutbuffer and about the primary selection, the problem remains that the
vncviewer cannot take the primary selection, because it's connection
with Xvnc isn't talking the X protocol.  In X's cutbuffer, you can just
copy stuff into it, and the stuff is (in effect) stored by X.  But with
the "primary selection" paradigm, the owner of the selection merely
tells X "Hey, X: I now own the primary selection, and if anybody asks
for it, tell them I have it", and then there's a protocol for anybody
who wants to paste the primary selection to contact the other X client
using the X server as an intermediary, and they hand off the data
between themselves.  This allows for applications to talk datastreams
that won't fit in storage, or in protocols that the X server doesn't
know.  But since the vnc *viewer* is not actually an X-protocol client
of the server, the server can't tell anybody that the vncviewer has the
primary selection; there's no way to say so in the X protocol. 

Now, mind you, I've only looked at the code superficially, and some of
my conclusions are based on how *other* apps interact with selection and
cutbuffer.  But as I said, I can see why it's not easy at all to get
"the right thing" to happen across the interface.  The X version of the
vncviewer could *get* the primary selection from whoever owns it on the
screen it's displaying to, but it still couldn't *offer* other processes
the primary selection.  Or so I currently grok.

And I don't think I've exhausted the list of complications yet, either.

As I said, it'd be nice if it all acted in a unified and seamless way,
and I'm sure that getting it to do so is just a Small Matter of
Programming.  And it's clear that as it currently is, it does what it
can.  But I can see that trying to get it to do so (akin to the way
xterm tries to unify the two concepts) would be like dancing acrosst a
minefield.  At night.  Under a new moon.  With an overcast.  In rubber
galoshes two sizes too large. 

So it goes.


Wayne Throop   throopw "at" sheol.org
               http://sheol.org/throopw
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at" uk.research.att.com
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------