Clipboard doesn't work on Ubuntu 20.04
makuto opened this issue · 8 comments
I have been trying to use Ctrl+C and Ctrl+V in gf, but it neither copies nor pastes. Is this something that needs to be hooked up in the app? I have 43091e7 and built from source.
Sorry, I tried once, but was ultimately unable to work out how to implement the X11 clipboard API.
Perhaps someone else will be able to figure it out.
Just started trying to implement clipboard for luigi textboxes. Will submit a pr there if I figure it out.
Got clipboard support working! All the changes are in luigi.h, and I've put "//@clipboard_change" near all the changes to make it easy to find them.
There is a little catch though, X11 makes it so that when you paste something it creates an event that the program you are pasting from has to respond to by sending over the data. Which means that in order to paste something you copied in gf you have to keep that text in memory. I'm not sure what your general policy for keeping track of that kind of stuff is, so for now I just created a giant global char array, and you can adapt that however you want.
Also when you close gf you lose whatever was in the clipboard (since the program is no longer there to copy from). A lot of linux programs just work this way, and the ones that don't just keep a process running in the background (or try to find a clipboard manager that continuously runs in the background) until the clipboard is replaced. I just went with the "close the program -> lose the text" approach.
I don't work with git much, so I'm going to try to submit a pull request, but in case I fail, here is the pastebin of luigi.h:
https://pastebin.com/hHuBT3S7
edit: I believe I successfully did a pull request.
Just started trying to implement clipboard for luigi textboxes. Will submit a pr there if I figure it out.
Oh wow that's a weird coincidence, I must have started implementing clipboard support an hour or two before you made that comment. Sorry I didn't post about it before doing so, although with the way X11 is, it might be good to have two solutions to compare.
Final note, I don't at all blame nakst for not figuring it out, what should have been a couple minutes tops with a remotely sane API turned into a total nightmare. I swear the X Foundation must have gone up to a mad man having a fever dream and asked "Could you design our API, here's some LSD so you can get creative with it!" And then for documentation, took the post-it notes he scribbled on and an ARG out of it.
Sorry for the rant, don't mean to be negative or be a drag, just had to get that off my chest.
Since I also got my solution working, you can see the pr here.
If the string is too large the property you are trying to read from will have an "INCR" atom type and its value will be the "lower transfer bound" for the incremental transfer X wants you to do. If you try to copy this string for example without handling incremental transfers you get this creepy smily face looking at you
Large string copying not working isn't a big deal here right now, I just thought it was funny.
@khvorov45 Thank you for also developing a solution. Unfortunately, you were slightly too late, and I already merged the other pull request. Would it be possible for you to send a pull request onto this repo (I will move the code to the luigi repo later), implementing your incremental transfer code against commit 654f316?
Please note that _UIProcessEvent is not reentrant, except in special cases for the dialog box. You will need to change this to either queue up input events and process them later, or discard them.
See #69.
There is still a bug here - inability to copy/paste within a gf window caused by incorrectly expecting the next event to always be SelectionNotify.
Merged. I think this issue may be resolved.