Using clipboard trough ssh

[microo8]

I have a TUI application, which could potencially run trough ssh.
It's a rss reader with sixel images: https://sr.ht/~ghost08/photon
There are keybindings to copy the rss item's link, or the item's image, for which I use the golang-design/clipboard library.

But when I run it trough ssh it just panics this:

panic: Failed to initialize the X11 display, and the clipboard package
will not work properly. Install the following dependency may help:

	apt install -y libx11-dev

If the clipboard package is in an environment without a frame buffer,
such as a cloud server, it may also be necessary to install xvfb:

	apt install -y xvfb

and initialize a virtual frame buffer:

	Xvfb :99 -screen 0 1024x768x24 > /dev/null 2>&1 &
	export DISPLAY=:99.0

Then this package should be ready to use.


goroutine 1 [running]:
golang.design/x/clipboard.init.0()
	golang.design/x/[email protected]/clipboard_linux.go:65 +0x4b

Is there a way to ignore the missing display and don't panic?
I know that trough ssh clipboard will not work, but that's ok.

[changkun]

Have you initialized the virtual frame buffer?

This

$ Xvfb :99 -screen 0 1024x768x24 > /dev/null 2>&1 &
$ export DISPLAY=:99.0

may help.

[microo8]

Thay might work, but what if the pc doesn't have xorg installed?

[changkun]

Then we can't use the package anymore. Clipboard is stictly depends on the desktop environment. Currently it supports X11 hence libx11-dev is required.

#6 speaks about Wayland support but it would also require another dependency for Wayland.

[microo8]

Yeah wayland support would be great. Anyway, I think panicking in `init` isn't great. It would be nice to import the lib without `libx11-dev` on the machine. It'll return a error or something and then I wouldn't call the lib if it weren't initializet properly. Because my app would work, just the copy feature wouldn't. But now it doesn't start at all.

[changkun]

That's a good argument. Does returning an error help your use case?

func Read(t Format) ([]byte, error)
func Watch(ctx context.Context, t Format) (<-chan []byte, error)
func Write(t Format, buf []byte) (<-chan struct{}, error)

Then this will be a breaking change.

[microo8]

That would be one approach. I had the idea of exposing a `Init() error` function. When the `Init` function returns a error, I wold know that calling `Read`, `Watch`, `Write` would panic. Also, the `Init` function wouldn't be needed. If I call eg. `Read` and the lib isn't initialized, it would call the `Init` function and panic if it returns a error. So nobody would have to rewrite their code. But returning errors is also ok, it's up to you.

[changkun]

That's a bit tricky. I like the idea of Init but not entirely sure if this is how we should proceed. The current Read/Write/Watch in fact ignored errors and does not return it to its callee. Returning errors might be the most proper way, but would also make all user code a bit ugly.

[changkun]

This is now avaliable at v0.6.0

[microo8]

Wow that was super quick and it works great, thanks :)