tal OP , 8 hours ago (edited 7 hours ago)

I figured I’d also add a bit of text about why I’m using wl-paste and clipman above, for anyone interested in clipboard management.

So, the specific problem I’m trying to solve with this daemon: On Windows and (traditional, dunno if this has changed, decades out-of-date on MacOS) MacOS, the desktop environment maintains a persistent clipboard buffer. When you hit Control-C (or, on MacOS, Command-C), the program tells the OS to save a copy of the copied/cut content.

This is not actually what X11 or Wayland do. Neither X11 nor Wayland maintain a persistent clipboard. What they do is act as a broker between two X11 or Wayland programs. So, if you you launch Program A and select text (for PRIMARY) or hit Copy (for CLIPBOARD) and then in Program B, middle-click (for PRIMARY) or hit Paste (for CLIPBOARD), then Wayland tells Program B to go get data from Program A.

For X11, this was particularly important in that the system was designed to run on very low-resource thin terminals. That terminal may not have the ability to store a whole lot of clipboard data.

This becomes user-visible If someone closes Program A prior to pasting in Program B, because their content also disappears.

Some people found this obnoxious, and introduced a solution many years back, reusing an approach used by software on Windows and MacOS to solve a different issue.

On both Windows and MacOS, some people ran into the limitations of having a single clipboard. They didn’t want a “copy” to destroy whatever was already in their clipboard, wanted a history.

Some software packages dealt with this – I believe Microsoft Office was among these – by introducing its own “clipboard history”. Emacs has its own sophisticated system with a history, the kill-ring, that’s been extended in all kinds of exotic ways (e.g. to be a “kill-torus”). But while these mitigate the problem for a particular important program, these are not system-wide.

So what folks on MacOS and Windows did was introduce “clipboard managers”. The idea here is that you have a very small, simple program. It just sits and waits for the clipboard contents to change. When they do, it saves a copy. It typically saves some finite number of clipboard entries, and lets you go back in a time-ordered list and choose saved clipboard contents. Some provide more-sophisticated functionality, like searching through history. That’s nice if you just chose “copy” and realize that you just blew away some content that you’d copied. Based on a quick glance, neither MacOS nor Windows ships out-of-box with a clipboard manager in the base OS in 2024, but it’s a simple program to write, so people who want it don’t have trouble adding it on.

X11 has three clipboards (PRIMARY, SECONDARY, CLIPBOARD) and Wayland can do at least PRIMARY and CLIPBOARD, dunno about SECONDARY. That’s a bit more state that can be retained, but they aren’t really intended to provide a “history”.

Some people on X11 or Wayland also want that “clipboard manager” functionality. And a “clipboard manager” also has the nice side-benefit of providing clipboard persistence beyond the lifetime of the program from which you copied the data. You don’t have the “Program A was closed before pasting to Program B” issue, because what happens is that you copy in Program A, then the clipboard manager detects that the clipboard contents have changed and internally transfers the clipboard contents from Program A to its own memory, then announces that it has new clipboard contents, a copy of what was just stored, so when the user pastes in Program B, he’s actually asking the clipboard manager to send data to Program B. I don’t actually know how fast the clipboard managers detect new data in the clipboard – depending upon how the clipboard API works, I suppose that there might be a window for data loss, where someone copies in Program A and then immediately closes Program A – but it seems to work well-enough on a day-to-day basis.

This is particularly obnoxious for software packages like xsel on X11 and wl-clipboard on Wayland. They’re command-line programs that you can use to “copy” text. They need to provide the appearance to the user of looking like any other command-line program and exiting once they’ve run. But the X11 and Wayland protocols don’t permit for that – a program from which one is copying data has to stay alive long enough to send data to whatever program is requesting it. So xsel and wl-clipboard have to fork off a process to stay alive until the clipboard contents change, which is kind of a kludge.

I don’t personally need a clipboard manager. I don’t care about a clip history. I use emacs’ kill ring, but the overwhelming remainder of copy-pasting I do is very simple. And my experience has been that clipboard managers tend to come-and-go, and tend to be tied to a particular desktop environment or widget toolkit, and come with a bunch of library dependencies.

What I do want, though, is clip persistence past the lifetime of a given program. I don’t like having to think about whether a program is still running or not. I want the clipboard to act like my X11 server or or Wayland contains an independent clip buffer, and when I choose “copy”, it saves a copy to the thing.

The combination of clipman plus wl-paste --watch can be made to act as a very minimalist clipboard manager. It doesn’t use KDE or GNOME or GTK or Qt or anything like that. All it does is talk directly to Wayland. That fits my bill well. Note that it does store a copy of the clipboard on-disk, which some people may want (so that it lasts across sessions, which I don’t care about). That’s necessary because wl-paste doesn’t retain state and clipman doesn’t stay running. Some people may not like this in that they may not want clipboard contents sitting around on disk from session to session; stuff like passwords might be persisted there; just a heads-up. There are clipboard managers out there that won’t persist state to disk, if that’s a concern for anyone.