(WIP/PoC) Add wayland clipboard support#1583
(WIP/PoC) Add wayland clipboard support#1583trimental wants to merge 5 commits intoalacritty:masterfrom
Conversation
303f80d to
9dfc0d0
Compare
|
@francesca64 Is a clipboard interface API within the scope of winit or should this be the proper way to access the clipboard when using the wayland backend? It does require the creation of a whole separate event queue that must dispatched regularly along with the creation of a lot of wayland objects. |
|
Clipboard support is in scope for winit, as discussed here: rust-windowing/winit#162 There's no API design decided on, but I'm not too particular about it. |
9dfc0d0 to
a2dbfd0
Compare
|
I'm running this and Wayland clipboard integration seems to work well for me with these patches. (whereas the standard xclip-implementation doesn't work at all when copying from a native wayland application to native wayland alacritty) Thanks! |
|
According to comments on rust-windowing/winit#695 it seems that clipboard API may be considered out of scope for winit (at least at the present moment) If rust-windowing/winit#695 gets accepted without clipboard API in its scope then this PR could probably be considered an actual PR instead of a PoC |
7c53934 to
aece977
Compare
|
I've tried the branch and found two issues:
|
|
@ojab I cannot replicate the first issue and assume that it would be to do with sway instead of this branch. The second issue I could replicate however I don't believe wayland has the concept of a second clipboard and perhaps sway supports two clipboards purely because of XWayland, @vberger is my understanding correct? |
aece977 to
6126d3a
Compare
|
There is a wayland protocol for primary selection, see https://github.com/wayland-project/wayland-protocols/tree/master/unstable/primary-selection. |
|
Yes, this protocol is the way forward for primary selection. However, not that sway does not support it yet (see swaywm/wlroots#1367 ). |
|
I've proposed it upstream to make the decision clear that clipboard handling is out of scope for winit. Hopefully this should make it possible to move forward with alternative solutions. @trimental I'd be interested in potentially dropping Alternatively it would be possible to make It also seems like this is using the |
|
A decision has been made on IRC that @trimental is going to try and offer this functionality as a separate crate. Hopefully we'll be able to include this into the |
|
Meanwhile support of primary-selection-unstable-v1 was added to sway: swaywm/sway#3735 |
This PR is a work in progress / proof of concept for wayland clipboard integration into alacritty.
The way this PR accesses the wayland clipboard can be seen as kind of a hack (its not explicitly bad but comes with compromises and probably isn't the intended way to access the clipboard), the reason the 'proper' way isn't used is because it would require winit to either expose internal wayland objects that would cause winit breakage and instability or winit would have to provide a clipboard api interface (I'm not too sure what winit's stance on this is).
Currently wayland is used for the clipboard backend if
.set_wayland(wayland_display: *mut c_void)is called on theClipboardobject, I'll probably try to make a better way of setting wayland such as using a building pattern or something and split up linux.rs into a linux directory in src like winit and glutin does.The way the wayland clipboard functions at the moment is that it spawns a new thread that takes the
wayland_displayand uses it to create various needed wayland objects, the thread then loops every 50ms (this can be any value and is the balance between clipboard access time and cpu usage) and checks every loop for wayland events and/or requests from the main thread to do things like store or load data.The code quality is pretty bad at the moment because its still a WIP but the code should show the necessary changes required for wayland clipboard support.