-
Notifications
You must be signed in to change notification settings - Fork 62
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
Any way to better work around --paste-once #152
Comments
So super ugly PoC (I have never done C before): static void* paste_cleanup(void* arg) {
struct copy_action *copy_action = arg;
pthread_detach(pthread_self());
sleep(1);
cleanup_and_exit(copy_action, 0);
pthread_exit(NULL);
}
static void pasted_callback(struct copy_action *copy_action) {
if (options.paste_once) {
pthread_t ptid;
pthread_create(&ptid, NULL, &paste_cleanup, copy_action);
}
} This works, but ugly for a lot of obvious reasons. for some reason the sleep needs to be super long. 0.5 seconds wasn't enough which absolutely blew my mind. I would have expected clients to reread the clipboard within a couple of milliseconds lol... anyway after playing around with this myself, I see why it's probably not a good idea to implement something like this. |
Hi! So what you're asking for is essentially being able to add a timeout to
which would wait for the first paste request much like In fact, I like this much better than |
@bugaevc yeah I exactly that was the idea. For my purposes it was still too clunky of a workaround, so instead I just avoid chromium/electron clients now 🤷♂️ There might still be value for other usecases though. If you don't mind the threading in the codebase, my code above works. |
So yes I have read and I understand all the --paste-once issues. The problem is that in my script, using a timeout and --clear is not a proper workaround.
Usecase: My script copies multiple values one after another, waiting for the user to paste in-between.
With --paste-once this works great (in clients that support it).
With a timeout, I would have to instead send out a notification after each timeout and it's a tradeoff between tediously long timeouts and the user possibly missing one paste...
I guess the best workaround would be combining --paste-once and some small timeout for clients that request multiple pastes. I actually tried that in a script, by running:
but the problematic clients are not happy with that approach, so I think it would instead have to be supported in wl-clipboard itself. Opinions?
The text was updated successfully, but these errors were encountered: