Enable Wayland, Windows, and macOS clipboard support

[Slackadays]

Is your feature request related to a problem? Please describe.
If I want to use clifm's clip plugin on any system which doesn't have X11 and xclip installed, I'm out of luck.

Describe the solution you'd like
My project Clipboard supports X11/Wayland/Windows/macOS and is very similar to use as xclip. So, the solution I'd like is to replace xclip in the clip.sh plugin with clipboard to enable support across all of these platforms all at once.

Describe alternatives you've considered
You could add cases where you use wl-clipboard and pbcopy/paste and clip to the clip.sh script.

Additional context
I love the idea behind clifm and I love cross-platform compatibility, something which both clifm and Clipboard seem to be excelling at! 🥇

Edit: Looks like clifm doesn't support Windows natively, but only through cygwin. This should still work because CB will be separate from the clifm binary

[leo-arch]

Hi @Slackadays. First of all, congrats for Clipboard! I really like it.

True, the clip.sh plugin isn't cross-platform, and it should (whenever possible). Please consider hacking the plugin to add clipboard support (wl-clipboard should be added as well, agreed) and submitting a PR. The main idea would be to let the plugin automatically detect what is available and use the proper tool. And yes, a few case statements should do the trick.

[Slackadays]

I was thinking of the alternate cases as an alternative implementation in comparison to Clipboard, but it would work either way.

[leo-arch]

I'm thinking of something like this:

#!/bin/sh

CLIP_APP=""

if type wl-copy > /dev/null 2>&1; then
    CLIP_APP="wl-clipboard"
elif type xclip > /dev/null 2>&1; then
    CLIP_APP="xclip"
elif type clipboard > /dev/null 2>&1; then
    CLIP_APP="clipboard"
else
    printf "clifm: No clipboard manager found\n" >&2
    exit 1
fi

case "$CLIP_APP" in
    "xclip") ... ;; # Here we add whatever command is appropriate for the current use case
    "wl-clipboard") ... ;;
    "clipboard") ... ;;
esac

[Slackadays]

I've been spending a few hours trying to diagnose why clip isn't actually a valid plugin action, and even if I add the proper line in actions.clifm and config.c, it doesn't actually "show up" in clifm at all. Is this a known issue?

Edit: I fixed it by going nuclear with uninstalling clifm (through sudo find / -name clifm) and then re-cloning it, applying the clip=clip.sh lines, and then installing it again.

[leo-arch]

Yes, clip isn't enabled by default, and the reason is that this plugin is currently pretty crappy: it requires file names to be absolute paths and doesn't work at all with file names containing spaces. Working on it.

Thanks for pointing this out.

I'll let you know as soon as I have a decent working version.

[Slackadays]

Luckily, clipboard actually supports relative filenames and directories, so that's something you don't have to worry about there.

[leo-arch]

That's nice! However, since one of the options of the clip plugin is to import files in the clipboard to clifm's Selection Box, and since this latter requires absolute file names, I still need them to make the plugin fully functional.

[leo-arch]

Hey @Slackadays, FYI, the default clipboard manager in Haiku is named clipboard (see this link), which conflicts with your clipboard. Regarding this plugin, this is not an issue, since we can always check whether we are in Haiku, but this might be troublesome for you in some other way.

EDIT: Yes, I'm aware you provide also a cb binary, but still.

[leo-arch]

I've been playing around with cb. Sending files to the system clipboard works as intended, no problem. A simple

cb --copy < files.txt

works fine.

However, I need cb to print the raw contents of the system clipboard to STDOUT, exactly like xclip -sel clip -o or xsel -bo or wl-paste do.

1. If I use --paste, cb pastes the raw contents (this is fine) into a rawdata.clipboard file (which is not what we want here)
2. If I use --show instead, cb pastes the formatted content (no format needed here) into STDOUT (yes!)

Maybe I'm missing something, but, is there a way to print raw data to STDOUT?

[Slackadays]

@leo-arch The way you can send the contents to stdout is actually very simple, just cb | cat. CB automagically detects when you're piping data out of it and gives you raw access when you use it like that.

[leo-arch]

Great, working now.

Getting a few errors nonetheless when trying to copy to the clipboard (files are actually copied, but...).

cb --copy < $CLIFM_SELFILE

Complains:

xdg_surface@7: error 3: xdg_surface has never been configured (Wayland)
error: XDG_RUNTIME_DIR is invalid or not set in the environment (X)

Why this?

[Slackadays]

Did you build Clipboard in Debug mode? If so, then it spits out tons of messages every time it interfaces with a GUI clipboard. Also, what OS are you using in particular?

[leo-arch]

Running on Arch and installed from the AUR (clipboard-bin).

[Slackadays]

According to the author of the original code for Wayland, the xdg_surface error comes from a discrepancy of Arch from Ubuntu (which is where it was developed), and the XDG_RUNTIME_DIR error could be something from clifm or your system as Clipboard itself has nothing to do with it. See https://askubuntu.com/questions/456689/error-xdg-runtime-dir-not-set-in-the-environment-when-attempting-to-run-naut The xdg_surface error might be fixable, but it'll involve rearranging a bunch of setup functions.

[leo-arch]

Happening outside clifm as well. Also, it might useful to note that these messages do not pop up at all when doing the same operations (copy-to/get-from clipboard) with other implementations (xclip, xsel, wl-copy).

[Slackadays]

I'll see what I can do to fix these issues, I just need to get myself an Arch/Manjaro VM first

[leo-arch]

Just in case you need it, this is my setup:

Arch
X: i3, xterm
Wayland: sway, foot

[Slackadays]

Unfortunately, I'm unable to reproduce either of these errors either using Manjaro GNOME or KDE (both with X11 and Wayland), and the versions of Manjaro with i3/sway give blank screens in virt-manager, and Arch i3/sway were totally incompatible with VM displays.

So, this makes me think this is an Arch issue stemming from its bleeding-edge nature compared to Manjaro. This might seem odd, but the implementations of X11/Wayland in Clipboard are reportedly spec-complete and cover everything that i3/sway/arch might not be covering. I can only guess why xclip and wl-clipboard don't give these issues, though, but if I had to guess, it's from weaker MIME type handling and a few other features that don't trigger those errors because they are too incomplete. In short, these errors could be from spec-incompliance.

Edit: It might also be helpful if you added WAYLAND_DEBUG=1 before cb, like WAYLAND_DEBUG=1 cb to get a full report of what's happening.

[leo-arch]

Hey @Slackadays, cross-platform support for the clip plugin added in b1d5e3d. So, closing this issue.

I think it's better to open a new issue in the clipboard repo to keep track of a problem which has nothing to do anymore with clifm. Ok?

Btw, as soon as thing thing gets fixed, I'll reenable clipboard support in the clip plugin (it's already in the code, just needs to be uncommented).

[leo-arch]

cb support reenabled in the clip plugin.