Implement wlr-data-control protocol into Lipstick to allow system-wide clipboard for applications that rely on xclip/xsel

asked 2020-05-27 18:53:03 +0200

Kabouik gravatar image

updated 2020-06-05 13:00:28 +0200

Many applications that can be built on SFOS rely on xclip or xsel, however xclip/xsel cannot be built on SFOS because they have many X11 dependencies..

A nice solution would be to use wl-clipboard in combination with the wl-clipboard-x11 wrapper, so that applications that look for xclip or xsel would instead use wl-clipboard. wl-clipboard itself would also offer a way to access the clipboard from command line, which would have many potential uses. We have all the required dependencies to build wl-clipboard on SFOS, but unfortunately wl-clipboardcommands hang on SFOS for the reasons described in this Github issue: https://github.com/bugaevc/wl-clipboard/issues/85

According to the developer, a solution would be to implement wlr-data-control protocol into Lipstick:

The proper solution for this is for Lipstick to implement the wlr-data-control protocol; in that case wl-clipboard will work with it (without having to resort to focus stealing). Perhaps you could communicate it to Lipstick developers.

Should I report this somewhere else than TJC? Mer project maybe?

edit retag flag offensive close delete

Comments

2

That would be much appreciated @jolla.

mosen ( 2020-05-27 19:59:24 +0200 )edit

You can try to rename https://openrepos.net/content/alfmar/pbcopy to xsel

coderus ( 2020-05-28 11:16:22 +0200 )edit

Thanks for the idea @coderus. I used micro to test that because I know it looks for xclip for system-wide clipboard. No success with devel-su ln -s /usr/bin/pbcopy /usr/bin/xsel, but it slowed down micro's opening and closing, plus showed a white screen flicker temporarily when opening/closing micro. I suspect micro hangs a little when fetching the symlink to pbcopy because pbcopy throws warnings when we execute it.

I did the same with a xclip symlink instead of xsel, and that indeed appears to allow micro to use a system-wide keyboard. However, still the same slowness and white screen issue that make it suboptimal. I imagine it is again related to the pbcopy warnings, but at least it's partly functional.

micro is just a testing tool here, as an app that we know uses xclip. It likely also supports wl-clipboard too because I observed it hanging when copying text after I built a non-working wl-clipboard (due to the lack of wlr-data-control protocol, see Github link) on device. So proper wl-clipboard support would be ideal for our Wayland OS, and wl-clipboard-x11 on top of it for apps that support only xclip/xsel.

Kabouik ( 2020-05-28 14:03:37 +0200 )edit