Post by Harold L Hunt IIhttp://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.
Post by Harold L Hunt IIAn 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?
Post by Harold L Hunt III 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.
Post by Harold L Hunt IIHowever, 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.
Post by Harold L Hunt IINo, 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".
Post by Harold L Hunt IIEspecially, 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.
Post by Harold L Hunt IIHowever, after pasting from X to
windows, the clipboard doesn't get cleared when the selection is dropped.
Uhh... that is what we just fixed.
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.
Post by Harold L Hunt III 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?
Post by Harold L Hunt IIIt 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