Rethinking the Gnome Clipboard Issues(edu4rdshl.dev) |
Rethinking the Gnome Clipboard Issues(edu4rdshl.dev) |
Both reads and writes ends take some time, I played with it to see how various programs react to a writer that just hangs or takes a lot of time. If the read is handled synchronously then you can block a UI loop. Some implement timeout and some can be blocked indefinitely.
But handling in asynchronously (either on thread or in nonblocking event loop) isn't an automatic win either. For example the new gnome text editor didn't order other user inputs with clipboard; so you would press Ctrl+V, nothing happened initially, continue writing and suddenly the clipboard content was inserted.
And I don't even remember how the OpenGL hidden window inhibiting worked with wl_data_source. Since the window is stuck in eglSwapBuffers, does it get unblocked to handle the clipboard write?
Surprisingly, even though Gnome compositor doesn't have a clipboard manager, it caches the clipboard content sometimes.