This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: test case for clipboard hang?
- From: Lev Bishop <lev dot bishop at yale dot edu>
- To: cygwin-xfree at cygwin dot com
- Date: Tue, 30 Mar 2004 13:11:30 -0500 (EST)
- Subject: Re: test case for clipboard hang?
- Reply-to: cygwin-xfree at cygwin dot com
Harold wrote:
>Lev Bishop wrote:
>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.
I think you're misunderstanding the delayed rendering in windows. The
important thing is that *you only get one chance to render delayed* after
that, the rendered data is saved staticly to the clipboard and windows
serves up requests for that data directly without involving your program.
Setting delayed rendering for a format is like writing an IOU for that
format, but once windows has collected on the IOU it doesn't try to ask
you to pay twice, it only needs to be told the data once.
>>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.
But you surely agree that the user is expecting that at least the CF_TEXT
and CF_BITMAP that you paste both came from the state of the clipboard at
a given snapshot in time?
>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.
I know that PRIMARY and CLIPBOARD are intentionally different in X, and it
is good that xwinclip respects this important aspect of X behaviour, but
it makes the mapping between X and windows more complicated.
>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?
When a win32 app requests non-unicode, if non-unicode has never been
rendered for this selection then the current value of the selection gets
rendered to non-unicode; if non-unicode has already been rendered for this
selection then whatever the value of the selection was at the time it was
rendered gets pasted. The same is true for unicode: if unicode has not
been rendered for this selection, then the current value of the selection
gets rendered as unicode, if unicode has been rendered then the prior
value of the selection is returned. The chance for there to be a
difference between what is returned to win32 for unicode and what is
returned to win32 for non-unicode comes in if the value of the selection
changes between the requests. Some X clients do not reassert the selection
every time the value of the selection changes (eg xclipboard is one) to
minimize traffic to the server (this is encouraged in the ICCCM).
I don't think this is a bug in the unicode -- the unicode is treated in
the same way as the plain text. The problem is that potentially the
unicode and plain text entries in the clipboard can be from different
times and hence be different to each other.
>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.
The problem here is that the user cuts 2 pages out of a document he's
working on to the clipboard, then goes to paste it and we say "oops, the
data is missing, sorry" and the user says "damn, now I have to type those
2 pages out again".
>>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.
The former behaviour is acceptable, because it gives the user a chance to
avoid losing his data, the latter behaviour, while it does exist, is a
badly written app.
>>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
I do this, and paste is *not* greyed out in this case. And in fact the
paste actually works, too, because we have already rendered the text to
the clipboard, so the data is there and we don't need the original X
selection any more because it is actually stored in the clipboard. I want
to keep this behaviour -- I consider it a feature, not a bug.
On the other hand, if you skip step 2, then paste is indeed greyed out,
and this is also the right thing, because at this point we don't have the
text available to paste.
>>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.
NO! The data has already been rendered! You only have to render (only get
a chance to render) each type of data *ONCE*, and then it is there, in the
clipboard, in static form. Why would we want to go and delete perfectly
good clipboard data, that windows is serving up for us without needing
any further help from us?
>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.
This might work, if we could reliably tell when the X app is about to
exit or lose its network connection or whatever. I think this will be
hard.
I still think we can't really do much better given the limitations of the
windows vs X paradigms. More interesting is to try to add support for
additional formats. Another thing is to add support for the INCR method of
pasting large amounts to the clipboard. Currently the clipboard
integration can't deal with clients being considerate and using INCR
for large pastes rather than blasting the data out all in one go.
Lev