Hi Drew, 1 juillet 2019 21:08 "Drew DeVault" <s...@cmpwn.com> a écrit:
> Hey Victor! I want to quickly thank you for all of your hard work > allowing Wayland to flourish in the Rust ecosystem, along with the rest > of the community that supports you. Thanks! > Big +1 to more implementations of the Wayland protocol. wayland-rs is a > great example of this. However, if this discussion leads to "we should > replace libwayland upstream with something like this", hard NACK from > me. Such a move would shrink the pool of contributors, deeply affect > libwayland's portability (consider for example that I, personally, work > with Wayland on RISC-V, which is not supported by Rust), and > dramatically increase complexity and churn for questionable gains. I never imagined to actually replace libwayland with wayland-rs, but I understand how my original message may have felt like this. Sorry for not being clear enough. Coming from my history working on wayland-rs for 4 years now, there is something I can say for sure: libwayland's current API is *not* rust-friendly. As a result, wayland-rs contains a lot of boilerplate to fit it in a reasonable way into Rust's ownership model. I've at occasions seen on #wayland maintainers for other languages formulate similar complains. Now, I've partially solved this issue for Rust by also making a full-rust implementation of the Wayland protocol in wayland-rs. But as soon as one needs to interact with something else (notably Mesa for OpenGL or Vulkan), this is an immediate no-go, as Mesa and the client app must use pointers coming from the same Wayland implementation. This is why I came up with the idea of introducing an alternate API in libwayland, which would be more fundamental and more FFI-friendly. This would allow easier interop between the different languages and C libraries like Mesa or GTK. I'm thus proposing a tentative design of such an API, and the possibility of implementing in wayland-rs as an experiment. If this is something that people are interested in and the experiment is successful, then I can imagine two paths forward (there might be more though, my imagination is limited): - the newly designed API could be integrated into libwayland (but I expect this to require a significant refactor) - I could reasonably provide an implementation of the ffi-taylored API on top of libwayland's API (after all I'm already doing something similar with wayland-rs) This second path would mean (assuming the whole project succeeds) that users would then have 2 options: - use the current C libwayland-client, and optionally a libwayland-client-ffi built on top of it - use wayland-rs, which would directly implement libwayland-client-ffi, and provide a libwayland-client built on top of it However I have no interest in developing a Rust implementation of libwayland's API if I cannot use it in a better way than the C implementation from Rust. So if this project is not welcome, I'll just stick to what I have currently: "You can use the Rust implementation only if you don't need Vulkan, openGL, or any interop with a Wayland-aware system library". Victor _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
