| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
Also improve code to better match the situation described in the FIXME
|
|
|
|
|
|
| |
This avoids an error message in a special case:
nxagentRemoteToLocalAtom: WARNING failed to get name from remote atom.
|
| |
|
|
|
|
| |
This ensures the convert will be sent out immediately.
|
| |
|
| |
|
|
|
|
|
| |
This helps making people aware that their debug logs might contain
sensible information.
|
|
|
|
| |
printing the wrong client makes the debug output very confusing ;-)
|
|
|
|
|
|
|
| |
Instead of passing the target to the remote side and then receiving an
"invalid target" reply we can do that check directly (if the target
cache is filled). This way we can save some more roundtrips due to the
target cache.
|
| |
|
| |
|
|
|
|
|
|
| |
for ICCCM conformity
Fixes ArcticaProject/nx-libs#969
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Normally you'd expect the loop going up to NumCurrentSelections. But
the dix code will increase that number (but not nxagentMaxSelections)
when drag and drop comes into play. In that case this helper will
report a match for other selections than the ones the clipboard code
knows about. The subsequent code will then use a higher index which
will lead to out of range data reads (and writes!). Therefore we take
nxagentMaxSelections here. The startup code ensures that both arrays
will refer to the same selection for the first nxagentMaxSelections
selection atoms.
This way the clipboard code will not kick in for drag and drop
resources.
Fixes ArcticaProject/nx-libs#986
|
|
|
|
| |
Let them return -1 which makes it easier to check for successful execution.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This may seem unneccessary at first sight because we are only talking
to our own clients which generally is quick. But if you are using
nested nx sessions or clients from remote machines (e.g. via ssh X
forwarding) this still can save some lenghty communication.
Plus: it helps in debugging because there are fewer messages being
sent around.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some applications (e.g. Chrome, Firefox) send multiple TARGETS
requests when they want to paste a selection (reason currently
unknown). If such an application runs in an NX session and the current
clipboard owner is on the real X server this triggers many
(superflous) roundtrips.
By caching the first answer to those requests and answering subsequent
requests from the cache we can eliminate all this communication.
The implemention resulted from attempting to fix
ArcticaProject/nx-libs/issues/#969 (solution 1a) but it turned out
that the speedup this brings does not help in reducing the number of
requests by firefox. It must be a bug in the firefox code.
Nevertheless I kept the code as it should speed up the whole pasting
process considerably while reducing communication over the wire.
This also eliminates a memory leak in the target forwarding code which
was unnoticed before.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Also reduce number of certain DEBUG lines:
These PropertyEvents tend to appear quite often and most of the times
they have nothing to do with the clipboard. So instead of printing
them everytime we turn that around and print something only if it is a
clipboard related event..
|
|
|
|
|
|
|
|
|
|
| |
In the "none" case we must ensure the clipboard data is reset. This
"optimization" skipped the reset part which made the code think it is
waiting for an answer. Which (of course) never arrived. So any further
request was rejected...
Also reduce debugging output for the "none" case because
resetClientSelectionStage will print it anyway.
|
| |
|
|
|
|
| |
we do that everywhere when handling clipboard stuff
|
|
|
|
| |
The code took the wrong path because of an insufficent check
|
| |
|
| |
|
|
|
|
| |
This helps reading the debug output a lot!
|
| |
|
| |
|
|
|
|
| |
They are ancient and their use is discouraged by ICCCM
|
|
|
|
| |
textclipboard=<bool> in the options file
|
| |
|
| |
|
| |
|
|
|
|
|
| |
we currently do not support them but as they require a special
treatment we need to know them and report an error if they appear.
|
|
|
|
|
|
| |
Internal clients asking for the available targets for a selection will
no longer get a predefined list but a the list of targets from the
owning client on the real X server.
|
|
|
|
|
|
| |
Clients on the real X server requesting the available targets for a
selection will no longer get a predefined list but a the list of
targets from the owning internal client.
|
| |
|