Any way to better work around --paste-once

[MatthiasGrandl]

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:

wl-copy -f -o "foo bar"
wl-copy "foo bar"
sleep 0.1
wl-copy --clear

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?

[MatthiasGrandl]

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.

[bugaevc]

Hi!

So what you're asking for is essentially being able to add a timeout to --paste-once, like this:

$ wl-copy something... --paste-once --timeout=1s

which would wait for the first paste request much like --paste-once does now, but instead of shutting down immediately, it would wait for another second (still allowing paste requests), and only shut down then?

In fact, I like this much better than --loops proposed in https://github.com/bugaevc/wl-clipboard/pull/68. With --loops, you'd have to fine-tune the number of loops for every client individually; if the value is too low, the client just won't paste, and if it's too high, your private data will unexpectedly stay in the clipboard. Whereas with --timeout, you can set any reasonably long timeout (such as 5 seconds, even), which would be enough for the client to paste, but would still guarantee that wl-copy quits even if the client actually pastes much faster than that.

[MatthiasGrandl]

@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 :man_shrugging:

There might still be value for other usecases though. If you don't mind the threading in the codebase, my code above works.