[db48x]

This design dates back to X Windows (and probably before). It does indeed allow for various optimizations of that sort.

A clipboard manager is simply a program that initiates a paste into it’s own window as soon as any other window announces that it has the selection. It then advertises itself as having the selection, so that the the user can ultimately paste the data wherever it should go. The clipboard manager can persist the clipboard state, maintain a history of recently copied items, etc.

[account42]

You'd expect the Wayland design to improve on that to allow clipboard managers to work 100% reliably and efficiently by only being able to take over the clipboard just before the previous owner closes - just like how Windows does it. Better yet would be to integrate that behavior into the server.

[db48x]

You don’t want to integrate it into the server, because that limits choice. There are a lot of features that you could put into a clipboard manager that not everyone would want, and you don’t want to force everyone to just have the least common denominator of those features.

For example, one commenter pointed out that he uses one that keeps a permanent database of everything he has ever copied. Maybe you want to sync your clipboard between computers, while I just want mine to keep the last 10 clipboards and throw away the rest. (Actually I use Emacs which has it’s own internal kill-ring, so I don’t use a clipboard manager.)

[account42]

I'd want the server to provide the baseline functionality to keep up the illusion that Ctrl+C copies into the clipboard, even accross application restarts. That doesn't preclude additional clipboard managers that do more (e.g. history) on top of that.

[db48x]

The protocol doesn’t support that feature. No wayland server or clipboard manager can add it. Applications don’t support it either.