LPC: Life after X

Surely the right design in a Unix-style system is: open /dev/clipboard, call some ioctls to interact with type and format information, and use mmap or splice to move the data. Tying the clipboard to the windowing system is as bad an idea as tying printing to the windowing system; it's just that it's convenient.

(Note, of course, that /dev/clipboard is a symlink to /proc/self/session/clipboard, which is a pseudo-device provided by the session manager for the session that a task belongs to, and the session manager's implementation of this device is responsible for handling exchanges like applications that see that the current clipboard content is a jpeg image, but ask for a bitmap, or see that something is formatted text and may ask for rtf or plain text. Also that the session manager is probably only acting as a directory for the clipboard manager to make itself known to clients. And I'm not going to get into how the clipboard manager needs to work, because I know that I don't know.)

Put another way: ICCCM is a de facto standard for this functionality and is an X standard, but the functionality actually has nothing to do with X. Any change away from X means that clients (or their toolkits) will have to change. Once they're changing, the right step is to do something that isn't particular to (e.g.) Wayland, because I want to copy/paste a URL from my TV to the IM client on my laptop by using my Android phone as a remote control (without interfering with the experience of the other people watching the TV, thanks). Obviously, that isn't going to just work immediately, but, when going to a new system for copy/paste, there shouldn't be any design limitations preventing it.