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?


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



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