Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How the clipboard works

whynothugo.nl

Post reply on HN
Print view View original

101–110 of 160 posts

Re: How the clipboard works

#101

Post by kevincox »

tantalor wrote: post #97

If the copy-side app is supposed to serve the selection whenever requested, then what happens if the user interaction causes the selection to change or be removed? e.g., editing text or navigating to another page Does the copy-side app have to keep that selection around in memory forever? That seems like a big downside. > A big upside of this design is that no data is copied around unnecessarily. That's only true as…

I think you are right but it is still an optimization in the common case.

1. If the owning app doesn't need it anymore it does need to keep it around until the clipboard is replaced, but this is likely still cheaper than copying. (For example if you are copying images you just need to reference-count the image, or if you are copying a table in an app with an undo history you are holding that data anyways, you just need to know how to rebuild the old version for the copy).

2. If the owning app is offering to do conversions (for example text/csv or text/html for a table) it only needs to hold one version in memory.

Of course this does add a lot of complexity to do it "well". However the app can always start with a simple implementation (just make a copy/reference count internally) then migrate to a better implementation when it makes sense.

It does seem to me that a hybrid implementation may have been the best. Apps can send data to the compositor (maybe via a sealed memfd) or just tell the compositor to ask for the data when it wants it. Maybe this could even be done per-content-type so that for example the app can send the `text/csv` to the compositor but if someone asks for `text/html` it can read the `text/csv` from the compositor then send back the `text/html`. But that would be an edge case, and still has a problem with closing applications. I guess when the application closes it can either 1. Upload the other content-types proactively before shutting down or the compositor just drops those types off of the clipboard leaving only the types that it holds itself.

Re: How the clipboard works

#102

Post by account42 »

db48x wrote: post #73
alkonaut wrote: post #68

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…

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…

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.

Re: How the clipboard works

#103

Post by account42 »

imiric wrote: post #27
enriquto wrote: post #18

No word about unix-style clipboard? Select to copy, middle-click to paste. If I had to highlight an immediate usability advantage of linux with respect to windows and macos, it would be clearly this thing. It feels "at home" when you can do this. Also, I have a viscerally strong disagreement with the following sentence: > The majority of the implementations out there are broken and only handle text. For me, one of th…

I don't think having two different clipboard implementations is a usability advantage. Only on Linux do you find yourself in the situation where one application copied to the Unix clipboard, and another tries to paste from the "secondary" (X11?) one. Standardizing on one implementation is the only sane path forward.

I have literally never run into applications mixing up the clipboard and selection on Linux - its always CTRL+C->CLIPBOARD->CTRL+V and select->PRIMARY->middleclick.

Super useful to have two different scratch buffers when moving things around.

Re: How the clipboard works

#104

Post by account42 »

enriquto wrote: post #57
Beltalowda wrote: post #49

Earlier quoted context omitted.

> It mostly ends up with me overwriting the clipboard unintentionally with data I don’t care about. I mostly find it really useful for "quick copies", like the quote from your post here. I don't really care if it gets overwritten because it's only relevant for a few seconds. For anything else you can still use ^C/^V on Linux.

> you can still use ^C/^V on Linux How do people stand these particular keybindings? They get so much in the way inside a terminal! They are possibly the worst choice of keys for something as important as copy/paste (if the keyboard is needed at all, but I digress). ^C = forcefully stop the current program ^V = escape to enter the next character verbatim I use these two all the time, and I find it very confusing that…

Clipboard is a GUI thing, terminal emulators are just that - emulators. Not really surprising that there are clashes.

I don't find it too hard to remember to use Ctrl+Shift+C/V in terminals (when I don't just use the primary selection).

Re: How the clipboard works

#105

Post by ghusbands »

bobthepanda wrote: post #4
texaslonghorn5 wrote: post #3

Good refresher, nice share. I wish there was a little more transparency in the clipboard. When I press WinKey+V, Windows 10 only shows me one format but often pastes a different one (obviously) -- would be nice to have the option to allow me to look into the possible formats I can get out.

I know in Word and maybe other MS products you usually get an option of * keep source formatting * match destination formatting * text only

None of which quite do what they say, in my experience. For actual text-only pasting, I often end up pasting into a fresh notepad, then copying that and pasting into Word. Otherwise, newlines at least sometimes get altered. Similarly "match destination formatting" often gets confused by formatting changes within the pasted text. I often end up pasting even formatted text via notepad and then recreating the formatting by hand.

Re: How the clipboard works

#106

Post by the_mitsuhiko »

lupire wrote: post #100
Beltalowda wrote: post #48

Earlier quoted context omitted.

It's disappointing to see Wayland copied X11's annoying clipboard semantics. I've been using X11 for so long I'm used to it now, kind of, but it still regularly bugs me or leads me to accidentally "lose" some things. Some time ago I tried to copy something to the X11 clipboard with a Go app, and this is basically impossible as Go can't fork into the background like xclip etc. do, so you need to either depend on a bit…

Why can't a Go program fork into the background?

Because go uses threads.

Re: How the clipboard works

#107

Post by TeMPOraL »

dns_snek wrote: post #46
jimmytidey wrote: post #31

Earlier quoted context omitted.

So essential - how often would I want the formatting in the obviously completely different context? I used to paste things into the URL bar to remove formatting. I've discovered a colleague does the same.

You might want to be careful about pasting anything remotely sensitive into the URL bar as most browser automatically send your query to the search engine for auto-complete functionality.

My habit on Windows, entirely in the muscle memory after two decades of doing it, is:

- If the text to sanitize is a single line: Win+R, paste, select all, cut, Esc (to close "Run" window)

- If it's multiple lines: Win+R, notepad, Enter, paste, select all, cut, Alt+F4 (to close notepad)

On Linux, I usually switch to Emacs, switch to a scratch buffer, then do the paste-and-cut-again dance in it.

Re: How the clipboard works

#108

Post by jeroenhd »

SeanLuke wrote: post #85
jeroenhd wrote: post #17

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/po…

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

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.

Re: How the clipboard works

#109

Post by spacebouy »

ClassyJacket wrote: post #38
robust-cactus wrote: post #12

Given how much memory we have available these days, would we build it the same way? Having copy paste usually work outta the box everywhere might be more valuable than memory savings. Sidebar: I do at this point use a copy paste history app anyways that saves and plain text-ifies everything.

What's the app?

I have been using ditto[0] for years and am happy with it.

[0] https://ditto-cp.sourceforge.io/

Re: How the clipboard works

#110

Post by wizzwizz4 »

wheybags wrote: post #96
the_mitsuhiko wrote: post #71

Earlier quoted context omitted.

> in Excel's case that question "Do you really want to quit? You have copied large amounts of data to the clipboard." even occurs when you have a single cell's worth in the clipboard That's not correct. You need to have quite a few cells in the clipboard for this to happen. > But that's also a confirmation question that no one really understands The dialog tells you exactly what it is asking for. It gives you three o…

Most users know about copy paste, but have no idea what "the clipboard" is.

Doesn't Microsoft Office still have a button in the bottom-right of the Cut, Copy, Paste section of the Ribbon (subtitled "clipboard") that opens a big Clipboard side panel?
Post reply on HN