-
-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion: Enable Pasting into X11/Wayland session after copying from terminal on Linux #14
Comments
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. |
Thats great news :). How is it with Wayland? |
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, |
@Hubro as the Owner stated:
|
@PlexSheep The context of this ticket is specifically pasting from |
Fair enough. |
Writing to the Windows clipboard has been added in 652e890 |
Reading from the Windows clipboard has been added in ce4c204 |
X11 read support has been added in 98d260f 👀 @PlexSheep |
Thats great! next update will really be worth it. |
macOS read support has been added in f4ac182 (you can also check https://github.com/Slackadays/Clipboard/wiki/GUI-Clipboard-Compat) |
Full X11 support (copy and paste) is now available in 0.2.1 🙂 |
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 Does the X11+Wayland binary works for both but also for no GUI? 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 |
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: 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. Hopefully this can be handled by a single binary. Otherwise we'll have to choose one of the above options I guess. |
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. |
Alright then
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 |
It looks like that Stackoverflow post never claimed that you couldn't use |
👍 That would allow me to make |
Looks like
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 |
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 |
Would that change anything from a manual installation point of view? |
As long as we could condense the steps for building the libraries into the |
@Slackadays I think |
This Thread sounds like good progress, but still after installing it again (Fedora 37 using (Clipboard 0.2.1r2) When can we expect this feature to be in a release? Again thank you all for your great work :) Also I just noticed that |
@PlexSheep Would you mind manually compiling Clipboard as a Debug build? This will reveal everything with X11, and then we'll have more details to work with. |
Okay I will try compiling it myself. |
I just compiled it myself and copying and pasting from X11 clipboard to the cb program works fine. Anyways, this issues seems to be resolved now. |
Wayland support still isn't ready yet, so I don't know if this issue should be closed |
Is it a known thing that installation like the README says with I can reopen the issue until wayland support is in a release aswell. |
It should enable X11 support, but the X11 libraries may be different from what it expects or it could be some other issue. We can rule out the first one by adding |
This looks like an issue with the install script: it copies the executable to |
$ LD_DEBUG=libs cb &> /tmp/a.txt
(I reinstalled the curl version, copy/paste to/from X11 doesn't work with this one) |
Looks like Clipboard actually is searching the "right" path, but not the one the libs are installed to, because Fedora is a special case. The simplest fix would be simply to add |
The debug logs for the clipboardx11 lib seem to be the same as the ones i get on my arch linux install. Why did the clipboard work when i compiled it myself using the standard cmake commands? If I understand this correctly, I don't have to add anything to any cmake configs. |
Just added the install prefix path to my local build, and even though it will search
|
Do BOTH logs mention "opening an X11 connection"? |
When you do |
I think none do, which makes sense, as none of these versions work. Only the one I compiled on my local machine does. |
@PlexSheep The latest build should have a fix, so would you mind trying the install script again? |
I will try right now, give me a second |
This new cb version works for me on Fedora 37.
In fact, i copied these logs using the project. Not entirely sure what you did, but that fixed it. |
@PlexSheep @Hubro It's time to put this issue to rest, as complete Wayland support has been added as of c89b72e. However, the next release may not come for a couple days to allow time for simplification/bug fixing. |
@Slackadays I just tested out clipboard for Wayland, and there's possibly a bug. Whenever I copy something (for example |
@Hubro This is actually a feature of Wayland, although not a very nice one. Wayland only lets programs access the clipboard if they have a window with focus in order to improve security. This means that to access the Wayland clipboard, CB has to make a dummy window and give it focus just to get access. That window has a size and height of 1 pixel so it normally isn't visible. However, since sway will want to display everything in tiles, it picks up on that dummy window and causes the problem you see. So, to fix this, you'll either need to disable tiling, get sway to add a rule to not display 1x1 windows, or get Wayland to change the protocol to let CB not use a dummy window. Edit: I would say that little things like this are why Wayland is still considered half-baked, considering how this issue doesn't exist anywhere else. |
@Slackadays That's odd, wl-clipboard does this without opening any windows. I've been using |
@Davipb Any thoughts on this? |
While it's technically possible to create a In fact, wl-clipboard does open a window when getting data from So there's two possibilities: wl-clipboard is using a non-standard data device that doesn't require a focused window to get/set the clipboard data.
wl-clipboard is opening the window in a way that causes Sway to not show it. In fact that's already what happens for CB on GNOME: the opened window isn't visible even for a fraction of a second (I tested that when implementing the code). Maybe the way we open the window is enough for it to not show in GNOME but not enough for Sway. |
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.
The text was updated successfully, but these errors were encountered: