search

YaLTeR / wl-clipboard-rs

A safe Rust crate for working with the Wayland clipboard.
Apache License 2.0
255 stars 17 forks source link

Display parsing error under flatpak #32

Closed Doomsdayrs closed 1 year ago

Doomsdayrs commented 1 year ago

When running ruffle under flatpak, the main window cannot be created due to arboard not being able to access a clipboard, because is_primary_selection_supported is returning a false(?) under flatpak.

Source: https://github.com/ruffle-rs/ruffle/issues/9220#issuecomment-1396796671

Doomsdayrs commented 1 year ago

Maybe this is not this projects issue, but wayland-rs ?

YaLTeR commented 1 year ago

Hey! This is quite a weird error and I can't tell right away what causes it or who is to blame...

However,

Ruffle is a GUI app, right? Then it should not use wl-clipboard-rs to access the Wayland clipboard. GUI apps should use the normal Wayland clipboard data offer, which is usually exposed in a nicer way in the GUI library that you're using (I see mentions of winit, but it seems winit clipboard handling is not implemented yet?).

wl-clipboard-rs is meant for terminal or background apps that don't have their own window on the screen. To make that work on Wayland, you have to either use a non-standard protocol unsupported on major compositors (for a good reason), which is what wl-clipboard-rs does, or resort to hacks like spawning a 1x1 window for a split second which will steal focus and grab clipboard contents this way, which is not guaranteed to work and relies on auto focus behavior of most compositors (this is what wl-clipboard not-rs does).

So yeah, I understand it is more work, but I feel like finishing support in winit is a much better idea here, it will allow ruffle to access the clipboard on any setup with no hacks, as intended.

Doomsdayrs commented 1 year ago

@YaLTeR ruffle does not use wl-clipboard-rs directly. ruffle uses arboard arboard uses wl-clipboard-rs.

And yes, it uses winit for windows, but seems to be handling the clipboard by itself via arboard. So I can agree that winit clipboard support needs to be finished.

I just mainly want to dig down and see where this error is occuring. With my research last night, I now believe that arboard (even tho as you said, this library is not for GUI applications) & wl-clipboard-rs is not in fault but wayland-client under wayland-rs that might be.

YaLTeR commented 1 year ago

Oh, looking at that winit PR, I see a link to https://github.com/Smithay/smithay-clipboard

This crate provides access to the Wayland clipboard for applications already using some sort of GUI toolkit or a windowing library, like winit

Sounds like exactly what you need here? Smithay client toolkit is used for winit's Wayland backend, so I imagine this is as good as it gets short of the unfinished winit PR.

Doomsdayrs commented 1 year ago

wl-clipboard-rs is meant for terminal or background apps that don't have their own window on the screen. To make that work on Wayland, you have to either use a non-standard protocol unsupported on major compositors (for a good reason), which is what wl-clipboard-rs does, or resort to hacks like spawning a 1x1 window for a split second which will steal focus and grab clipboard contents this way, which is not guaranteed to work and relies on auto focus behavior of most compositors (this is what wl-clipboard not-rs does).

I believe the "resort to hacks" is what was going on, I will take this issue to arboard.

Sorry for the confusion!