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.
Keeping this open until we can read from the clipboard too.
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?
@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.
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.
So i will probably try to implement it the next days (will require to expose more of wlc's internals). A few questions:
get_clipboard and set_clipboard or rather clipboard set and clipboard get?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)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
Thanks for the pointers, am on it.
I don't think that this was actually resolved by Cloudef/wlc#273, although GitHub automatically closed this.
Is there a way to set the clipboard data from cli?
swaymsg clipboard "hello world"
Got it. Couldn't find it in documentation. I may send a PR to add it to the man page.
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.
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.
@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.
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.
@khughitt I found the following to work: for_window [title="wl-clipboard"] floating enable
@YaLTeR That did the trick! Thanks for the suggestion!
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.
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.
As mentioned in swaywm/sway#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.
Most helpful comment
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.