search

bugaevc / wl-clipboard

Command-line copy/paste utilities for Wayland
GNU General Public License v3.0
1.62k stars 60 forks source link

`wl-paste --primary` grabs keyboard maybe #50

Closed sentriz closed 5 years ago

sentriz commented 5 years ago

say i'm using sway and i've got this loop

while :; do
    wl-paste --primary
    sleep 1
done

and that's running in a terminal emulator. then i open another and i hold down the f key for example in it. it will repeat (fffffffff...) but only for one second then it will stop. i release the key and try again. again only ~1s or less. now kill the loop and i can repeat all day long

i wasn't sure why this was happening but then i saw https://github.com/bugaevc/wl-clipboard/issues/12 and now i'm thinking maybe this is related?

my question is 1) is this happening because wl-clipboard doesn't use wlr-data-control? 2) is using wlr-data-control in the works? or maybe it's already done - but i'm stilling having this issue with master

thank you for your tool :D

bugaevc commented 5 years ago

is this happening because wl-clipboard doesn't use wlr-data-control

Yes, not for the primary clipboard yet. For the regular clipboard it does, but the primary clipboard support was added to wlr-data-control later, and wl-clipboard still doesn't know how to use that.

is using wlr-data-control in the works?

There was a branch that supported some old revision of the protocol, and the upcoming 2.0 should also have full support for this. The main complication is that it's not trivial to figure out if a compositor that supports wlr-data-control actually supports primary selection or we should be using a different protocol (or outputting an error); it's possible, but you have to do things a bit differently (wait another roundtrip and see if a handler is called).

Do you want to contribute this? 😀

bugaevc commented 5 years ago

The master branch has the 2.0 beta now, which implements the above and no longer grabs focus if wlr-data-control is available.