This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: test case for clipboard hang?


Lev,

Lev Bishop wrote:

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.

That last sentence is not correct. Here is how delayed rendering works:


http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/dataexchange/clipboard/clipboardoperations.asp?frame=true#_win32_Delayed_Rendering

You'll notice in the clipboard integration source code that we advertise support for a format, but we only paste the data if it is still there; if the data is not there anymore, then we paste null data to satisfy the requirement that we paste something. This handles all of the cases were the X selection is lost for some reason or another and we are not notified about it synchronously.

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.

No, that is not correct. I can advertise CF_TEXT and CF_BITMAP and have a text that says "goat" and a bitmap rendering of a frog if I want. There is no requirement that the formats all contain the same data.


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 think part of what is happening here is that you are getting confused by the "feature" I added that intentionally lets PRIMARY and CLIPBOARD be different in X and only advertises the most recently changed one to Windows. However, it sounds like you may have found some sort of bug in the unicode handling... could you elaborate on what gets pasted if a in the cases were a Win32 app requests non-unicode and another Win32 app requests unicode text?


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.

No, it does when you use delayed rendering, which is part of the reason we use delayed rendering. This is not a big deal: we advertised something, it disappeared, *important* no other X or Win32 app placed something on the clipboard after we did, and we say "oops, the data is missing, sorry". What is the problem there? We owned the clipboard and didn't disrupt any other application from using it.


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.

You must not have worked with applications that give you the famous "you have copied a large amount of data to the clipboard, would you like to remove it to same memory" dialog box that pops up a few minutes after copying large data to the clipboard; some apps that use delayed rendering do the same thing when they exit but without warning: they just don't paste anything when they get a WM_RENDERALLFORMATS on exit.


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.

Yes, that is correct.


However, after pasting from X to
windows, the clipboard doesn't get cleared when the selection is dropped.

Uhh... that is what we just fixed.


I just tested it:

1) select text in xterm
2) paste in notepad
3) drop selection in xterm
4) right-click in notepad, see that paste is greyed out

If you are still seeing this then it is a more sophisticated bug than the recent fix was designed for and it may be the bug that I am currently working on, but it is hard to say.

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.

No, this is not correct. If the data is gone we shouldn't be pasting it because it means that we are likely referencing an already freed pointer and it will lead to random crashes.


It is remotely possible that we may be able to request selection contents when an X app is about to exit so that we can make a static copy of that text on the clipboard, but I don't know of a way to do this and it isn't important enough for me to spend time on right now.

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 probably due to some changes that Kensuke and I were making to which formats we advertised... I am real leary of changing this since it tends to break things on Japanese computers. I'm not sure if pasting NULL for CF_TEXT when we paste real CF_UNICODETEXT data would cause Windows to automatically convert from CF_UNICODETEXT to CF_TEXT like it says it will. Might be worth a try.


(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).

Interesting.


There's no easy way around this one either.

I wouldn't be so sure about that.


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

No, it needs to be better.


Harold


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]