> 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
