Add clipboard support to x0vncserver #1831
Conversation
| @@ -181,10 +181,13 @@ XDesktop::XDesktop(Display* dpy_, Geometry *geometry_) | |||
| if (XFixesQueryExtension(dpy, &xfixesEventBase, &xfixesErrorBase)) { | |||
| XFixesSelectCursorInput(dpy, DefaultRootWindow(dpy), | |||
| XFixesDisplayCursorNotifyMask); | |||
|
|
|||
| XFixesSelectSelectionInput(dpy, DefaultRootWindow(dpy), xaCLIPBOARD, | |||
| XFixesSetSelectionOwnerNotifyMask); | |||
There was a problem hiding this comment.
How difficult would it be to also support the selection clipboard?
There was a problem hiding this comment.
It should not be very difficult, but it does brings in this problem. So a similar approach will be needed here.
unix/x0vncserver/XDesktop.cxx
Outdated
|
|
||
| // When a client says it has clipboard data, request it | ||
| void XDesktop::handleClipboardAnnounce(bool available) { | ||
| if (available) server->requestClipboard(); |
There was a problem hiding this comment.
Could we wait until another application requests it? It would avoid transferring things needlessly.
There was a problem hiding this comment.
Sorry, didn't see you had already mentioned this.
It's not a requirement to fix this, but it would be nice if it's not too much work.
There was a problem hiding this comment.
Sorry for not being clear, but in PR summary I was talking about how current code issues XConvertSelection() commands immediately on a clipboard change on server side, without first calling announceClipboard(true) and waiting for handleClipboardRequest() call from VNC client. But I already have a solution to do it the 2nd way.
As for the server->requestClipboard(); here, my main motivation was to start with a simple working solution. Retrieving the clipboard from VNC client after another app requests it means that we need to queue that request (and potentially others) and fulfill it later when data is available. As you said, it would avoid needless transfers, and I am hoping to implement it.
Although, requesting it immediately means that when user selects 'Paste', the data is available immediately without potential lag. It also avoids the problem mentioned above about owning multiple selections, as the data will always be cached.
There was a problem hiding this comment.
I tried to implement this lazy loading, but it really complicates things. In addition to the issues mentioned above:
- Eventually transferred data can be larger then MaxCutText, so selection ownership needs to be released in that case
- Can't rely on
TXWindowto generateSelectionNotifyevents, becauseselectionRequest()will only add the request to queue.
So, I plan to keep this simple for now. Because in many cases, data will be immediately transferred anyway (needing to cache data if one selection ownership is lost, clients doing unsolicited transfer, clients not supporting extended clipboard).
There was a problem hiding this comment.
Okay. We can have that as a possible future improvement.
|
👍 👍 |
| // FIXME: We don't support clipboard yet | ||
| Configuration::removeParam("AcceptCutText"); | ||
| Configuration::removeParam("SendCutText"); | ||
| Configuration::removeParam("MaxCutText"); |
There was a problem hiding this comment.
Could you update the man page as well now that these are available?
gujjwal00
force-pushed
the
x0vncserver-clipboard
branch
from
f714ab0
to
d5e28f6
Compare
gujjwal00
force-pushed
the
x0vncserver-clipboard
branch
from
d5e28f6
to
1387a19
Compare
|
Updates:
|
gujjwal00
force-pushed
the
x0vncserver-clipboard
branch
from
1387a19
to
c23be95
Compare
|
Ok, I want to test it. How do I install this version where clipboard works for x0vncserver on Debian 12? |
Most of the groundwork related to selections is already present in
TxWindow. AndXDesktopalready makes use of XFixes, which can provide a notification whenever selection changes. I have addedXSelectionto handle the rest (took some notes fromvncSelection.cin Xvnc).CLIPBOARDselection is handled for now (because I don't personally usePRIMARY). Is this sufficient?vncSelection.cseems to only request data from selection owner when explicitly asked by clients inhandleClipboardRequest().I didn't want to make it too complicated before getting some feedback.
Issue: #529