Hacker News new | ask | show | jobs
by the_mitsuhiko 1331 days ago
> 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.

2 comments

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.