I personally find it more convenient to have pasted data written to
the X11 PRIMARY selection, so that I can paste it with a fast middle-
button click, than to write to CLIPBOARD which typically needs a key
sequence or menu action.
This commit adds a command-line option to let me express that
preference: now I can say "/clipboard:use-selection:PRIMARY" on the
command line, which not only enables clipboard transfer but also says
which X selection I want it to talk to. The previous options
"+clipboard" and "-clipboard" are also still supported.
A selection owner is supposed to respond to a request for the
selection target TIMESTAMP by providing the X server time at which the
selection was written. There was a /* TODO */ comment in xf_cliprdr
where the code to do that should have been.
The absence of this can cause a problem when pasting into some X
clients. xtightvncviewer, in particular, will give up the attempt to
read from the clipboard at all if it doesn't get a satisfactory
response to the initial TIMESTAMP request - and the non-answer zero
value "CurrentTime" counts as unsatisfactory. It won't be happy with
anything short of a real X server time value.
(Checking the VNC source code, that's because it reads both PRIMARY
and CLIPBOARD and picks the one with the later timestamp. So it does
depend on the timestamps existing.)
When you're writing to the selection in response to a normal X event
like a mouse click or keyboard action, you get the selection timestamp
by copying the time field out of that X event. Here, we're doing it on
our own initiative, so we have to _request_ the X server time. There
isn't a GetServerTime request in the X protocol, so I work around it
by setting a property on our own window, and waiting for a
PropertyNotify event to come back telling me it's been done - which
will have a timestamp we can use.
According to the channel docs, this field is only used in format data
request. Therefore, there's no need to hold it in the response. cliprdr
server code was copy-pasted from client code, therefore this must be
some leftover.
Clipboard formats containing plain text are specified to be terminated
by a \0 character in MS's documentation on standard clipboard formats:
https://docs.microsoft.com/en-us/windows/desktop/dataxchg/standard-clipboard-formats
xf_cliprdr_server_format_data_response receives pasted data from the
server to transfer to the client, in a sufficiently raw form that the
\0 terminator is still present, so it has to remove it. It does so by
checking only at the very end of the data. But I've observed that when
pasting out of at least one Windows program (namely Outlook 1903 on
Windows 10), the intended paste data arrives in this function followed
by \0 and then a spurious \n. In that situation the null-terminator
removal will fail to notice the \0, and will leave both bogus
characters on the end of the paste.
Fixed by using memchr to find the _first_ \0 in the paste data, which
should not lose any actually intentional data because it's in
accordance with the spec above.
The file clipboard delegate needs a base URI to operate on for
systems that are not WIN32. Added that to the context and abort
conversion, if that is not set. (currently not fully implemented)
The data provided by local applications can be actually encoded in
UTF-16 (e.g., Firefox does this to HTML). UTF-16 allows embedded null
bytes so we should not use strlen() to fix up the data. The HTML format
synthesizer can handle trailing null bytes just fine and can detect
whether it deals with UTF-8 or UTF-16.
Most of the functions is this file are internal-use callbacks so they do
not need to be exported from the compilation unit. Mark functions static
as appropriate.
