> A callback method that you can define to do anything you want in your program when the OS hands you the result of a user initiated paste operation because your program had focus. If you want custom keybindings to initiate the paste operation, you can register that desire with the OS.
Wonderful! Now how does this brilliant little solution account for applications that don't centre their operations on the keyboard?
How does this work for clicking on a UI element to paste?
How does this work for using non-tactile forms of input - say, a voice command?
How does this work for any method of interaction that's not "press a combination of keys"?
How does this interact with the very real and undebatable need to allow programs to simulate keyboard events?
What happens to operating systems that have the implementation of a system clipboard as out of scope (like a little-known operating system called Linux)? How does, say, the X window server then manage to implement a clipboard on top of it?
> rolling your own GUI and defining keybindings doesn't mean that you control access to the interface. The operating system mediating the hardware does that.
I am very curious indeed: what, exactly, do you think happens when (for example) a C program calls `getchar()`?
> But let's stop making "steal my secrets" part of the fucking standard system API and start working toward a brighter tomorrow.
If you consider something a secret, then may I suggest that you don't (both as a user and as a developer) put it in the general shared buffer for applications? The whole point of a buffer for temporarily storing and transferring data between applications is for said applications to actually access it. You are doing the equivalent of saving your "secret" in plaintext in your home folder and then complaining about the OS if/when a program peeks through your generally accessible home folder and finds it.