Re: test case for clipboard hang?

[Lev Bishop <lev dot bishop at yale dot edu>]

> Also, there is no fundamental incompatibility here, only an imperfect 
> handling of all of the cases that we need to handle. We can do this 
> perfectly, it is just confusing and takes time to get it correct. So I 
> am going to release 4.3.0-66 and you're going to test it. :)

I think there is a fundamental incompatibility, due to the following.  
Windows thinks of the clipboard as a fixed, centralized thing, that
doesn't change or delete data without specific user action (a useful 
conception from a user-friendliness point of view). X allows selections to 
change, get dropped due to the client getting disconnected, because the 
clipboard is not centralized but kept with each client (a useful 
conception when clients are accross a network from each other). Windows 
allows apps to delay rendering of clipboard data, but only insofar as from 
the user's point of view the behaviour is the same as if the data were 
saved to the clipboard in their final form at the time of the copy/cut 
action. An implication of this is that if the clipboard holds the same 
data in multiple formats, all the formats should still be the same data, 
eg, the same string in unicode and ascii. 

Can you see a problem? It is possible (and I have done it) for there to 
be 4 different conceptions of the clipboard, all holding different data! 
To demonstrate this, do something like: assert the PRIMARY selection by 
selecting text in an xterm; assert the CLIPBOARD selection by running 
xclipboard; type some text into xlipboard and paste the text as unicode 
into windows, eg edit->paste in excel; change the text in xclipboard and 
paste the text as plain text, eg using "paste special" in excel; finally 
change the text in xclipboard. At this point, there are 4 different 
"clipbaord contents", no two of them the same. X clients that ask for 
PRIMARY get one thing, ones that ask for CLIPBOARD get another, windows 
apps get 2 different things depending on whether they ask for unicode or 
plain text. This breaks the windows clipboard idiom of the data being 
fixed and immutable, and "the clipboard" being a consistent concept with 
just one thing in it, stored in different formats.

I can't see a way around this issue. 

Another issue is that in windows, data doesn't get deleted from the
clipboard unless you specifically ask it to be, or replace it with
something new. Especially, if you've successfully pasted something,
demonstrating that the clipboard has the data you want, that data won't
disappear unless you do something to get rid of it. Now, the x PRIMARY
selection is much more ephemeral than this, and it gets dropped all the
time. The recent patches in -63 mean that the windows clipboard
(correctly) gets cleared at the same time as the selection is dropped, if
the text has not yet been rendered.  However, after pasting from X to
windows, the clipboard doesn't get cleared when the selection is dropped.
I can't work out which part of the code is responsible for this behaviour,
but it works, and this is the right thing(TM) because now the windows user
can paste repeatedly, even if the original X client has been killed, in 
the way that windows clipboard usually functions. But here there is also a 
problem: if the selection is dropped after the text has been rendered in 
one format (say unicode) but not in another (say plain text), then, 
because there is no way at this point for xwinclip to retrieve the plain 
text from the client, it cannot honour its promise to render the plain 
text content of the clipboard. (This is how I was able to activate the "2 
second timeout" code, by the way: make an X selection, paste it as 
unicode, drop the selection, attempt to paste as plain text).

There's no easy way around this one either.

But, as I said, these are pretty pathological cases. So long as nothing 
crashes in these cases, I think that is good enough. 

Lev