This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
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