1. 37
  1.  

  2. 6

    Instead of binding to wlroots, using Smithay and contributing to it might feel better :)

    1. 3

      As mentioned, I considered it but wanted to learn how wlroots works first.

    2. 2

      Just for reference the “Way Cooler Postmortem” was also a little bit discussed over here, including a comment by OP.

      1. 2

        It’s a good finding that it’s not just the memory allocation/freeing semantics of a program that matter on porting to rust, but also how people manage to pass data between functions and the lifetimes of such. Perhaps reference counting and pinning memory can help when maintaining the “never moves” style of some C implementations?

        The passing of an inner pointer with a type code to allow dereferencing the outer data structure is a pretty clever way to avoid void*!

        1. 2

          So unsurprisingly unless your language uses the c-way, you’ll have trouble trying to integrate with anything relevant on *nix ? At least that’s the message I get from this. (The article is really interesting, I’m just disappointed about this cruft and that this is the solution in the all-new wayland.)

          1. 10

            It varies. Some libraries map very well, and are pleasure to use. When they fit, Rust can add borrow checking, thread-safety and automate memory management on top of existing C code.

            When a C library has straightforward memory management rules, like “every widget_init must be followed by widget_free”, it works great. The more the it goes towards “if florp flag is 3, then XOR the pointer with the name of your pet and dealloc &ptr[-17]”, the harder it gets to explain that to the borrow checker.

            It’s worth noting that it’s never a showstopper. As the article says, you can always shrug and wrap the whole code in unsafe or keep it in check with runtime assertions. The trouble is self-inflicted when Rust programmers bend backwards to have everything zero-cost and guaranteed safe.

            1. 6

              Wayland is in my experience actually fairly uniquely hard to integrate with from rust. People have been integrating with all sorts of other “relevant” things without trouble. For example kernel modules, x11, various foreign languages like writing python modules in rust, or even eBPF in the kernel, integrating with user space libraries like gtk, and so on and so forth.

              1. 5

                wayland-rs contains both a from-scratch Rust implementation and a libwayland binding. If you don’t need to use EGL or Vulkan, you can get away with the pure Rust implementation… but yeah, libEGL/libvulkan themselves use libwayland (and xlib/xcb, and equivalent native things on other platforms) so you can’t exactly give them your objects from your custom implementation of the protocol.

                1. 3

                  Yes, the protocol itself fits Rust fairly nicely, but a window manager without accelerated graphics for at least the clients is pretty much worthless. Last I checked it wasn’t (reasonably) possible to do that without libwayland integration.

                  Curiously that readme says

                  There are also two auxilliary crates:

                  • wayland-egl, which is necessary client-side for OpenGL integration

                  I might have to look into what that means/if they managed to avoid the libwayland requirement somehow.

                  1. 3

                    No, of course that crate is meant to be used with the libwayland option. If you wanted to avoid the requirement, you’d have to reimplement the actual libwayland-egl.