-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
egui-winit: Fix unsafe API of Clipboard::new
#2765
Conversation
The old API allowed passing an arbitrary pointer. The new API still breaks safety by allowing the object to outlive the input, but is at least safer.
Co-authored-by: Emil Ernerfeldt <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
I think it would be good to document in crates/egui-winit/Cargo.toml
that the wayland
feature is required to get the clipboard working on wayland.
Co-authored-by: Emil Ernerfeldt <[email protected]>
Without the |
needs |
|
Updated. Wasn't expecting you to push to my branch, 😆 . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Clipboard::new
So,
window_clipboard
is not (very actively) maintained and I had a look around...copypasta
is maintained, supports the "primary" clipboard, but makes no attempt to provide a Wayland-X11 abstractionarboard
is maintained, supports HTML and uncompressed RGBA images, but makes no attempt to provide a Wayland-X11 abstractionegui-winit
does have this abstraction, but with an unsafe APIsmithay_clipboard::Clipboard::new notes:
This change addresses the first point (prevents calling
Clipboard::new
with an arbitrary pointer).Addressing the second point with Rust's lifetimes would probably be very frustrating. I haven't tried. Addressing it by marking
Clipboard::new
andState::new
asunsafe
would be another approach, but would result in all code withinState::new
being compiled inunsafe
mode, would violate your#[forbid(unsafe)]
policy and is probably needlessly onerous (given that observing broken behaviour is unlikely), so I opted merely to add documentation here.I ran
sh/check
butegui-glow
failscargo check --all-features
(on X11). Nothing to do with me.