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