Clipboard
Clipboard copied to clipboard
Slackadays
Suggestion: Enable Pasting into X11/Wayland session after copying from terminal on Linux
This project does all copy pasting one would want, but is restricted to the terminal. It would be a useful addition to be able to copy to the system clipboard and paste the systems clipboard using cb.
This is actually already WIP, but X11 is such a crusty old legacy API that it could be a couple releases before we get anything like this, so stay tuned.
Wayland currently has nothing yet, as I'm finishing up a couple more features before I can get X11 working. (Check the changes-updates channel in Discord)
Doesn't seem to work with Wayland at all, actually. When I copy anything from a terminal or the browser, cb show shows nothing. If I copy something using cb, for example echo foo | cb copy then it isn't added to my clipboard (I can't paste it into the e.g. the browser.)
@PlexSheep The context of this ticket is specifically pasting from clipboard. Since I saw references to Wayland in the source code, I had assumed everything else (like copying) worked with Wayland. I wrote the comment to clarify.
Writing to the Windows clipboard has been added in https://github.com/Slackadays/Clipboard/commit/652e8905434ae1f3f9a21e6dfb2167fdd81b1630
Reading from the Windows clipboard has been added in https://github.com/Slackadays/Clipboard/commit/ce4c2042cf36bb0eeafe9f612cd94f5be66d94b5
X11 read support has been added in https://github.com/Slackadays/Clipboard/commit/98d260fac4c39eea9966f105b974515d9221228a 👀 @PlexSheep
macOS read support has been added in https://github.com/Slackadays/Clipboard/commit/f4ac182e13f9fadaedaeea7f976ea373b773d768 (you can also check https://github.com/Slackadays/Clipboard/wiki/GUI-Clipboard-Compat)
Hi, I'm the maintainer of the clipboard AUR packages.
Since v0.2.1 came out, there's now 4 different prebuilt binaries (no GUI, X11, Wayland and X11+Wayland) and I'm wondering which one the clipboard-bin AUR package should provide since there's no way for the PKGBUILD to determine whether the end-user has no GUI or is using X11/Wayland.
Does the X11+Wayland binary works for both but also for no GUI? If so, is there any reason to provide the other binaries (since this one alone could cover all scenarios)?
Thanks in advance :)
X11+Wayland works for both, but because that build is linked against the X11 and Wayland libraries, if the user doesn't have both libraries installed, then the X11+Wayland version won't even start up. Perhaps you could check if the user has libx11 or libwayland installed to see if it would work?
X11+Wayland works for both, but because that build is linked against the X11 and Wayland libraries, if the user doesn't have both libraries installed, then the X11+Wayland version won't even start up. Perhaps you could check if the user has
libx11orlibwaylandinstalled to see if it would work?
If not sure I can elegantly check for installed packages on the end-user machines and decide which binary to install according to it via the PKGBUILD unfortunately. Isn't that something that can be managed by the program/binary directly (e.g. "if libx11 is installed, then [...])?
In the current state, I guess the three options we have as far as the AUR is concerned are:
1 - Create 3 new AUR packages associated with each binary (in addition of the current clipboard-bin package): clipboard-x11-bin, clipboard-wayland-bin, clipboard-x11_wayland-bin
2 - Either delete the clipboard-bin package and/or advice people to preferably use the clipboard/clipboard-git packages which will build clipboard directly on the end-user machine with the correct features according to their configuration (right?).
3 - Make x11 and wayland dependencies for the clipboard-bin packages and install the x11+wayland binary everytime.
Option 1 is obviously more work from a maintenance side and makes things more complex. But if this cannot be handled by the program/binary itself, that would probably be the only way to package the multiple versions correctly. Option 2 is a bit more "radical" and only works because the package will be built on the end-user machine directly thanks to the AUR, which wouldn't be the case on official repo for instance (tell me if this need clearer explanations). While it looks like the easiest solution, I'd like to avoid option 3 because it is not very elegant in my opinion...
Hopefully this can be handled by a single binary. Otherwise we'll have to choose one of the above options I guess. What do you think?
Unfortunately, this can't be handled by the program/binary, because the library requirement happens before any code runs. So even if there was logic to handle this, it could never run because Linux insists on loading all the necessary libraries before doing anything. See this link: https://stackoverflow.com/questions/15951672/loading-linux-libraries-at-runtime
I think that the best solution is to make libx11 and libwayland dependencies because they don't have to do anything other than be present. If there is no X11 or Wayland compositor available (only the libraries), then Clipboard should still work because the errors are hidden unless you enable Debug Mode.
Unfortunately, this can't be handled by the program/binary, because the library requirement happens before any code runs. So even if there was logic to handle this, it could never run because Linux insists on loading all the necessary libraries before doing anything. See this link: https://stackoverflow.com/questions/15951672/loading-linux-libraries-at-runtime
Alright then
I think that the best solution is to make libx11 and libwayland dependencies because they don't have to do anything other than be present. If there is no X11 or Wayland compositor available (only the libraries), then Clipboard should still work because the errors are hidden unless you enable Debug Mode.
I initially wanted to avoid that since it didn't felt right forcing users with no GUI to install both X11 and Wayland. But if it's just the libraries, that should be fine indeed :)
Could we remove the hard requirement for libx11 and libwayland from the ELF header and try to load them at runtime with dlopen? If they fail, we assume that the system doesn't have that UI system installed and skip the code path.
It looks like that Stackoverflow post never claimed that you couldn't use dlopen to use shared libraries, just that it won't work if the filename is different from what you specify. If you can get it working, we could make a 0.2.1 Hotfix version to solve this problem once and for all.
Could we remove the hard requirement for
libx11andlibwaylandfrom the ELF header and try to load them at runtime withdlopen? If they fail, we assume that the system doesn't have that UI system installed and skip the code path.
:+1: That would allow me to make libx11 and libwayland optional dependencies which feels better honestly.
This way, people using the clipboard or clipboard-git packages will automatically get X11 and/or Wayland support (depending if their system has libx11 and/or libwayland installed) and as far as prebuilt binaries are concerned, you can provide only one that should work in any case.
Looks like dlopen doesn't relocate symbols for objects that have already been loaded, so we have two options:
- Remove
libx11andlibwaylandas compile dependencies entirely, usedlsymto load all of their functions/variables dynamically at runtime (e.g.display = dlsym(HANDLE_X11, 'XOpenDisplay')('DisplayName') - Move the part of Clipboard that talks to X11 into a separate object (e.g.
libclipboard-x11.so), ship that with the Linux executable and try to load it from the main clipboard executable (iflibx11isn't installed on the system it'll fail since that's a hard dependency onlibclibpard-x11.so's ELF header). Do the same for Wayland, leading to three objects total (main executable, x11 code, wayland code).
Option 1 lets us keep all code into a single CMake target and therefore into a single standalone file for distribution, but it would make programming much more error-prone, since there'd be no compile-time checks to ensure you're calling a function correctly at all. We'd also have to duplicate everything that is lost at compilation on our side (macro definitions, structure definitions, etc).
I'm more partial to option 2. It would require us to split Clipboard into three CMake targets and distribute it as three files, but it makes it much easier to maintain/fix the code in the future. We could mitigate the issue of having to distribute it as three files by embedding the x11 and wayland libraries into the main executable and extracting them to /tmp at runtime, which would be transparent to the user.
I like the second option as well, because the first would seem better, but like you said we lose a lot of error checking and need more boilerplate. Hopefully it's possible to implement the second elegantly. Considering how we already have temporary folders to use, unpacking and loading should be easy, but embedding the files could be difficult because C's embed only made it into the latest C standard and won't be coming officially to C++ for years.
Would that change anything from a manual installation point of view? If so, that's not a problem. It's just to know if have to adapt the PKGBUILD accordingly.
As long as we could condense the steps for building the libraries into the cmake --build . step, it should be no different because I believe CMake allows you to create multiple compile targets.
embedding the files could be difficult because C's embed only made it into the latest C standard and won't be coming officially to C++ for years.
We can start by shipping three files for Linux, as a minimum viable product. If that works as expected, we can start thinking about embedding and whatnot, but that's a late-stage optimization.
@Davipb Nice! Thanks a lot.
I updated the packages accordingly, making libx11 and wayland optional dependencies.
~~One last thing though. I noticed that the building logs still report lines related to X11/Wayland support. For instance, on a "no GUI" system:~~
[...]
-- Could NOT find X11 (missing: X11_X11_INCLUDE_PATH X11_X11_LIB)
-- Building without X11 support
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.8.0")
-- Checking for module 'wayland-client'
-- Package 'wayland-client', required by 'virtual:world', not found
-- Building without Wayland support
[...]
~~Is this intended? Maybe I understood things wrongly or I'm missing something but I thought that clipboard would always build with X11 and Wayland support out of the box as of now; but the associated code snippets would only execute if libx11 and/or libwayland are detected at runtime (if that makes sense).~~
EDIT: Forget it... It's only the provided prebuilt binary that has X11/Wayland support out of the box, right? My bad, I messed things up in my brain for some reason :laughing: Anyway, we should be all set now. Thanks once again for your actions!
EDIT: Forget it... It's only the provided prebuilt binary that has X11/Wayland support out of the box, right?
I know you already figured it out, but just to make it explicit to anyone else reading: to build Clipboard fully you still need X11/Wayland installed, but they're no longer required to run Clipboard. Building the project without X11 will cause libclipboardx11.so to not be generated, which means that the executable you built won't support X11 even on systems that do have it installed (the same goes for Wayland).
@Antiz96 What are the requirements to put Clipboard onto the main Arch repo other than having one package for binaries? If there have to be certain features, then maybe we could work on those.