However, the drawback is that it runs forever. Without the main loop, it finishes, but the clipboard contents are not set correctly, which I assume is because the events are not processed.
Is this a correct assumption?
If so, is there a way to “drain” the main loop and make sure all events are consumed before exiting?
If not, if there are better ways to do this from a script than the above?
i.e. it calls the on_change immediately after clipboard.set is called, so it doesn’t really give the indication whether the clipboard was actually updated, just that the update was triggered.
That’s the whole problem though. When main_loop.run() gets called, eventually clipboard gets set. I’m trying to figure out how to determine when that happens, so I can main_loop.quit(). The above doesn’t ever quit because main_loop.quit() is called before main_loop.run(), but it’s not a solution for scripts which need to exit in reasonable time.
main_loop.run
<Gio.Task object at 0x7f141507e180 (GTask at 0xf48c90)>
exception g-io-error-quark: Cannot store clipboard. No clipboard manager is active. (15)
main_loop.quit
done
so main_loop.run() happens before the callback (which is good) and main_loop.quit() works as expected (though there’s that “no clipboard manager” exception), but apparently that’s too soon as well - the actual clipboard contents do not get set.
$ while true; do xclip -o -selection clipboard -t TARGETS; xclip -o -selection clipboard; sleep 1; echo; done
Error: target TARGETS not available
Error: target STRING not available
As you can see, it prints errors, which disappear when I leave the main loop running.
I guess that without a clipboard manager, which X11 presumably does not have, the providing process has to stay running to transfer clipboard data to clients.
No, that’s not the case. As long as the providing process says on long enough (I presume in order to process all the events that copy the data to the clipboard), the data is saved into the clipboard.
Stopping the process does not remove it from the clipboard or make it otherwise inaccessible to the requesting process, nor does the requesting process need to request it while the providing process is up.
(process exits immediately as the app does not have any windows)
So it looks like with plain GLib.MainLoop the “clipboard manager” (mentioned in gdk_clipboard_store_async documentation) does not get started (or connected)? Hopefully someone wiser than me could give some insight.
I’m on NixOS unstable. Wondering if there’s something fundamentally different between the two distros or maybe there’s something I need to do on my end for this to work.
Here are the versions of what may be relevant on my machine: