Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interact with Wayland clipboard via cli #926

Closed
embik opened this issue Oct 3, 2016 · 22 comments · Fixed by Cloudef/wlc#273
Closed

Interact with Wayland clipboard via cli #926

embik opened this issue Oct 3, 2016 · 22 comments · Fixed by Cloudef/wlc#273

Comments

@embik
Copy link

embik commented Oct 3, 2016

As long as there's no clarification on #913 (how to manage interaction between X and Wayland clipboard) I'd love to interact with sway's clipboard via a cli application such as swaymsg. I'm using pass which is using xclip by default. It would be lovely to pipe passwords from pass (or any other cli application) into the Wayland clipboard.

@ddevault
Copy link
Contributor

ddevault commented Jul 1, 2017

Keeping this open until we can read from the clipboard too.

@embik
Copy link
Author

embik commented Jul 2, 2017

Thinking about this I'm not sure if reading from the clipboard is a feature you want to implement? As the copy to clipboard functionality works over swaymsg, wouldn't it be possible for malicious processes to read the clipboard if there was a swaymsg get-clipboard?

@neon64
Copy link

neon64 commented Jul 3, 2017

@embik, I imagine if swaymsg get-clipboard was ever implemented, it would be disabled by default by sway-security, but you could override that by editing /etc/sway/security.d/. Although I guess that depends on sway-security being 100% secure which afaik I don't think it is at the moment.

@ddevault
Copy link
Contributor

ddevault commented Jul 3, 2017

You can also do things like run swaygrab to capture the screen or swaymsg to use swaymsg's IPC permissions. Part of a secure system is sandboxing things you want to keep under control, which includes removing access to swaymsg -t get_clipboard from the equation.

@nyorain
Copy link
Contributor

nyorain commented Jul 5, 2017

So i will probably try to implement it the next days (will require to expose more of wlc's internals). A few questions:

  • should it be get_clipboard and set_clipboard or rather clipboard set and clipboard get?
  • is it enough to handle text support (i.e. text/plain targets, simply fail if the cilpboard cannot provide this) or is anything else required? (it might be possible to dump other clipboard targets but it is probably not worth it IMO, would require a rather huge wlc interface addition)
  • (sorry, still not too familiar with the codebase) where is security handled? is there an example of an command dealing with security (or isn't it handled by the command implementation directly?

@ddevault
Copy link
Contributor

ddevault commented Jul 5, 2017

should it be get_clipboard and set_clipboard or rather clipboard set and clipboard get?

Well, sway commands cannot output information, similar to i3 commands (I want to change this in the future - but not now). For the time being you should add a new IPC message type and we can use swaymsg -t get_clipboard.

is it enough to handle text support (i.e. text/plain targets, simply fail if the cilpboard cannot provide this) or is anything else required? (it might be possible to dump other clipboard targets but it is probably not worth it IMO, would require a rather huge wlc interface addition)

Sure, that's fine for now, but don't paint us into a corner such that we can't change that later.

(sorry, still not too familiar with the codebase) where is security handled? is there an example of an command dealing with security (or isn't it handled by the command implementation directly?

You get security for new commands for free, you should just set their permissions appropriately in /etc/sway/security.d/00-defaults if the defaults aren't sufficient. For the new IPC message, however, you will have to do a bit more. Add a new feature type:

https://github.com/SirCmpwn/sway/blob/master/include/sway/config.h#L223

Then, when you implement it in ipc-server.c, check it with something similar to this:

https://github.com/SirCmpwn/sway/blob/master/sway/ipc-server.c#L353

And add an IPC subcommand so that this can be configured:

https://github.com/SirCmpwn/sway/blob/master/sway/commands/ipc.c

@nyorain
Copy link
Contributor

nyorain commented Jul 5, 2017

Thanks for the pointers, am on it.

@clarfonthey
Copy link
Contributor

I don't think that this was actually resolved by Cloudef/wlc#273, although GitHub automatically closed this.

@tmccombs
Copy link
Contributor

Is there a way to set the clipboard data from cli?

@ddevault
Copy link
Contributor

swaymsg clipboard "hello world"

@tmccombs
Copy link
Contributor

Got it. Couldn't find it in documentation. I may send a PR to add it to the man page.

@emersion
Copy link
Member

emersion commented Aug 6, 2018

swaywm/wlr-protocols#20

@bugaevc
Copy link

bugaevc commented Sep 1, 2018

https://github.com/bugaevc/wl-clipboard

@emersion
Copy link
Member

emersion commented Sep 2, 2018

Note that @bugaevc's solution uses a hack to get keyboard focus (which spawns a transparent window, probably resulting in flickers in Sway because it shows up as tiling). This should be fixed by the clipboard manager protocol we're working on.

@bugaevc
Copy link

bugaevc commented Sep 2, 2018

Yes — and the plan is, when new protocol materializes, make wl-clipboard automatically use it instead of the transparent surface hack when running under wlroots-based compositors.

@khughitt
Copy link

@bugaevc @emersion Do either of you happen to know if there is anyway the window might be configured to spawn in the background? For example, I'm not sure if for_window rules take effect before the window is drawn, or after, but if they are applied before, and the transparent window is given a known instance id or class, one might be able to add something like for_window [app_id="wl-clipboard"] move scratchpad to their config to avoid triggering window tiling.

Right now the flickering is quite bad with Neovim / Sway - every time text is yanked, the window temporarily resizes / flickers.

@emersion
Copy link
Member

wl-paste uses a hack as of now. You're encouraged to contribute to make it so there's no hack anymore instead of making the hack more hacky.

@YaLTeR
Copy link
Contributor

YaLTeR commented Nov 23, 2018

@khughitt I found the following to work: for_window [title="wl-clipboard"] floating enable

@khughitt
Copy link

@YaLTeR That did the trick! Thanks for the suggestion!

@bugaevc
Copy link

bugaevc commented Dec 14, 2018

Right now the flickering is quite bad with Neovim / Sway - every time text is yanked, the window temporarily resizes / flickers.

This is now fixed in wl-clipboard master by using another hack — using the layer-shell protocol instead of xdg-shell, the popup surface can be made to float automatically; there no need for the user to configure anything.

As far as implementing a proper solution instead of a bunch of hacks goes,

Yes — and the plan is, when new protocol materializes, make wl-clipboard automatically use it instead of the transparent surface hack when running under wlroots-based compositors.

The new protocol is now implemented both from the Sway/wlroots side and from the wl-clipboard side, though neither implementation is yet merged into the respective master branches.

@emersion
Copy link
Member

This is now fixed in wl-clipboard master by using another hack — using the layer-shell protocol instead of xdg-shell, the popup surface can be made to float automatically; there no need for the user to configure anything.

Note that when security rules will be implemented, layer-shell will be locked down.

@devurandom
Copy link
Contributor

As mentioned in #1919 (a duplicate of this request) and swaywm/wlr-protocols#20: https://github.com/bugaevc/wl-clipboard is the current way of setting the Wayland clipboard from the command line. The issues regarding the transparent window appear to be resolved and the for_window config file adjustment mentioned above is no longer necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.