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/clipboard@v0.5.3/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 :)