Hacker News new | ask | show | jobs
by alkonaut 1336 days ago
What's the reason for this unusual no-actual-clipboard design? The user's mental model of a clipboard is that things are copied to the clipboard, so breaking that mental model has to have a reason?

Obviously this is more elegant for several reasons (performance, security/privacy) etc. But still: the fact that it doesn't survive a shutdown sounds problematic.

Can a clipboard manager fill that gap completely, i.e. copy and persist data so that apps don't have to take care of it themselves?

One huge benefit of the no-actual-clipboard design that I can immediately see is the fact that probably 99% of all cut/copy/paste operations are within the same application, and this design allows a shortcut where the data can be cloned as the application sees fit. For example, an immutable data structure can just be added as another reference. If I have two copies of an image resource in my document, I can just use the same image in both locations. With a serializing copy the cost of serialization for the copy must be paid up front because we can't know whether the same application will be the receiver.

3 comments

I assume it's meant as a simplification?

For comparison, when you copy something in Windows, for each offered format the software can decide to either immediately give the data to the OS for safe-keeping, or to just announce the availability of data in that format, and generate it on request. The intention obviously being that for example Excel might immediately put the text representation in the OS buffer, but only create the HTML version if anyone requests it. This was invented in a time when those CPU cycles mattered after all.

The wayland setup reads like someone looked at a Windows-like design, thought having two ways clipboard data could be handled was confusing, and decided to simplify it by axing the straightforward path that 99% of clipboard data takes.

I’m a windows desktop dev since the last millennium and tbh never knew that there was an announce api. It seems really difficult to use as a tiered solution where you only return the more complex data when asked. After all, you must then still snapshot that data from the moment the copy occurred to be able to provide a snapshot from the time of the copy later?
You snapshot the data in your application's native data format, then you can convert it later to the best match for the consumer.

Taking the Excel example form above: You got to store the cell layout and values. If it's pasted into a different excel sheet you pass that structure over. If it is pasted in a richt text editor it is converted to some richt text table format. If it is pasted to a plain text editor it is made tab separated or something and if pasted into an image editor it is renders into a bmp (well, Excel doesn't do that, but imagine ...) Doing all those conversions beforehand, just due to pressing Ctrl-C, is expensive as most of the time none is needed.

The Excel clipboard has a more complex model:

- If the copied data is pasted in the same Excel instance, then the system clipboard isn’t used at all and native Excel objects are pasted.

- If data is pasted in an OLE-enabled application (e.g. Word or PowerPoint), then an OLE-specific method is used.

- If the data is pasted into another Excel instance or into another application, then the system clipboard is used, but without the possibility to transfer native Excel objects, only csv, RTF, html, text, image, or an ancient spreadsheet-like format called SYLK.

And at any time during this process you can easily and readily lose the copy from Excel.

God its so annoying to tab back to the sheet to hit Ctrl-C again.

True, but doing it "right" (especially considering 1990ies hardware) isn't easy. And Windows has the option, to just pass it to the system, if you don't have complex needs (only copying plain text etc.)
Usually applications just delete the clipboard data announcement once it first changes in the application
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.

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.
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.)

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.
The protocol doesn’t support that feature. No wayland server or clipboard manager can add it. Applications don’t support it either.
“… the fact that probably 99% of all cut/copy/paste operations are within the same application…”

Depends. If you’re working, say, in an application writing or a drawing/graphic app then you’re likely doing a lot of copy and paste. In which case the total number of CnP operations is very high.

However, this measure is misleading to the utility of CnP between applications. Not having to save to a compatible format and then importing from the other app is a great productivity improvement.

Just saying.