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

Display parsing error under flatpak #32

Closed
Doomsdayrs opened this issue Jan 19, 2023 · 5 comments
Closed

Display parsing error under flatpak #32

Doomsdayrs opened this issue Jan 19, 2023 · 5 comments

Comments

@Doomsdayrs
Copy link

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: ruffle-rs/ruffle#9220 (comment)

@Doomsdayrs
Copy link
Author

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

@YaLTeR
Copy link
Owner

YaLTeR commented Jan 19, 2023

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
Copy link
Author

@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
Copy link
Owner

YaLTeR commented Jan 19, 2023

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
Copy link
Author

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!

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

No branches or pull requests

2 participants