Hacker News Reader

Comment by jeroenhd | Hacker News Reader

For those wondering about how Windows does this, there is, as you'd expect, a Raymond Chen article about it: https://devblogs.microsoft.com/oldnewthing/20210526-00/?p=10... (and some more, like https://devblogs.microsoft.com/oldnewthing/20220608-00/?p=10...)

Elsewhere in these comments there is also a link to an explainer for the macOS equivalent.

Here's also an explainer for X11: https://www.uninformativ.de/blog/postings/2017-04-02/0/POSTI...

It's interesting to look at these clipboard APIs together to see what may have led to the Wayland design, which is probably the most recently designed clipboard implementation.

I think the Wayland API is more elegant but also requires a clipboard manager in cases where you wouldn't expect to need tone (to copy less than a kilobyte of data before closing the program, for example).

View on HN

> It's interesting to look at these clipboard APIs together to see what may have led to the Wayland design

If that lead to Wayland then I think people took away the wrong lessons. Wayland's current protocol / API for clipboards is incredibly annoying. It's hard to deal with for applications, it's even harder to deal with for clipboard managers which were not really considered in that design and usually break the clipboard in different ways.

I have never seen that many bug reports and issues with clipboard behavior as with wayland. If there is a benefit to the design, then it's entirely non obvious to me.

X11/ICCCM clipboard semantics (which is arguably the same design, but with the server being part of the data transfer) was also source of many bugs and the applications/toolkits did not get it right until 00's and linux-centric desktop environments. IIRC disagreement about how to integrate Emacs' concept of kill rings with X11 selections was one of the major reasons for Emacs/XEmacs split.

> the applications/toolkits did not get it right until 00's

They have still not gotten it right. I still sometimes experience the clipboard losing things on modern Ubuntu.

X11's model for 'cut buffers', 'primary', and 'clipboard' is a historically bad design.

Like very easily in the top 10 worst designs in computer science history.

The fact that it managed to work at all is a testament to the millions of man-hours people were willing to pour into polishing a turd to make Linux Desktop a reality.

If we had the ability to go back in a time machine and do it again it is now painfully obvious that X11 should of been completely abandoned by the mid-1980s. This would of saved a huge amount of heartache.

Cut buffers are different thing than selections and cut buffers are deprecated and probably not used by anything written in last 25-30 years.

On the other hand cut buffers are so simple that there isn't any of the complexity as with selections. But still I think that the ICCCM/Wayland model of selections is the only sane way how to implement clipboard, because it does not involve creating some kind of shared state of potentially unbounded size and consuming potentially unbounded CPU time doing that even if it will not be used.

That's generally true of most things in Wayland. It's poorly designed and then badly implemented, by multiple different compositors in different ways, leading to endless bug reports and broken software.

What's so frustrating is that this is my Linux desktop experience since I have been using it. Clipboards not surviving shutdown where at one point not working, then a bunch of people got together to fix it up and now it's broken again. My Wayland experience is a massive flashback to 2004.

Yes, I know. I remember several years ago being super excited about Wayland. But every time I have tried it, it just falls over in so many different ways. I have given up.

About copy/paste in particular, I have solved it for myself because I work almost exclusively in the terminal and the browser, both of which stay running all the time and therefore acts as a clipboard manager for any copy/paste that happens in it. I am just waiting for my terminal of choice to get support for copy/pasting arbitrary mime types, which its maintainer has said he is going to implement.

> Elsewhere in these comments there is also a link to an explainer for the macOS equivalent.

I know you didn't mean anything by this, but given that the entire concept of a clipboard was invented by the Mac/Lisa team (the Xerox Alto didn't have one), it seems wrong to describe it as an "equivalent" to Windows.

Coming first doesn't make it less equivalent.

I don't think it was the Apple Lisa that had the first clipboard. Xerox definitely had a clipboard and other experimental environments had them as well.

The Lisa was the first to name it the "clipboard" but that doesn't really count in my opinion.

Also, modern macOS isn't based on the old mac operating system after switching to Unix, so even for Apple computers the macOS clipboard is an "equivalent" of the old clipboard.

> I don't think it was the Apple Lisa that had the first clipboard. Xerox definitely had a clipboard and other experimental environments had them as well.

Larry Tessler coined the terms "copy" and "paste" (basically just mark and yank) on early Xerox text editors. But AFAIK the Lisa group invented the Clipboard as a general storage mechanism for a variety of data types: and they certainly they coined the term. Here's a message from Bruce Horn, who is about as authoritative as it can get:

https://lisalist2.com/lisalist1/1796.html

> Also, modern macOS isn't based on the old mac operating system after switching to Unix, so even for Apple computers the macOS clipboard is an "equivalent" of the old clipboard.

Meh. The current MacOS clipboard is an amalgam of the NeXTSTEP pasteboard and the Carbon clipboard (derived from 9).

Yeah, windows let's the clipboard owner decide if they want to delay rendering per format.

That might be nice, especially if you are just copying a short amount of text before closing the window.

For X11 there are also the CUT_BUFFER0-CUT_BUFFER7 properties and XDND.

Reply on news.ycombinator.com