#192 fix clipboard fails due to missing timestamp problem
Summary: Don't abort a clipboard operation on a failed timestamp transfer.
This way a clipboard can at least get through, not terribly useful
as the primary selection can't win if there is a clipboard, and
if there isn't, it doesn't bother with the timestamp.
X clients that register selections for clipboard and primary
selections are supposed to support the TIMESTAMP query to find out
the time that they acquired the selection. Not all clients support
the timestamp query. rdesktop will pull from either the primary or
clipboard selection when a Unix to Windows clipboard operation is
requested, if only one of the two is currently owned that one is
selected for a transfer. If both are owned rdesktop sends both
selection owners a timestamp request and selects the newer of the two
for the clipboard operation. Without this patch if both primary and
clipboard are owned, rdesktop aborts the transfer on the first failed
(not supported) timestamp query, this is very non-obvious and
difficult to clear. The user just sees clipboard transfers fail
randomly and until the application that doesn't support timestamps
looses its selection clipboard operations Unix to Windows fail.
Currently if a client returns a timestamp of 0 it is set to 1 for the
purpose of comparing the to selection timestamp values. rdesktop uses
0 to mean it has not yet received a timestamp for that application. A
returned 0 timestamp value indicates the client supports timestamp,
but probably used 0 when acquiring the selection in the first place
even though clients are not supposed to. This patch will set the
timestamp to 1 for any client that doesn't support timestamps so at
least a transfer can take place even though it can't know for sure
which selection is the newest and will select the clipboard over the
primary selection in the case of a tie.
better clipboard selection logic