wlc Bindings for Rust

Completely safe and idiomatic bindings to the wayland compositor library.

Documentation

Example

// for a more functional example see /examples/example.rs
use wlc::*;

struct Compositor;
impl Callback for Compositor
{
    fn view_created(&mut self, view: &View) -> bool
    {
        view.set_visibility(view.output().visibility());
        view.bring_to_front();
        view.focus();
        true
    }

    fn view_focus(&mut self, view: &View, focus: bool)
    {
        view.set_state(ViewState::Activated, focus);
    }
}

fn main()
{
    wlc::init(Compositor).unwrap()
}

Usage

This crate currently requires nightly Rust to mark certain ffi-related structs explicitly as not Send.

You can opt-out of this behaviour with a feature-flag (unsafe-stable). Make you never pass View, Output including their Weak-Variants, Positioner or Wlc to another thread.

Add to your Cargo.toml

wlc = "0.1"

For stable

wlc = { version = "1.0", features = "unsafe-stable" }

For static compilation (combination is possible)

wlc = { version = "1.0", features = "static" }

See wlc for build dependencies, when doing a static build.

Additionally libclang>=3.8 is needed for code generation during build.

If you have libclang in another path then /usr/lib you have to provide it when building your binary:

LIBCLANG_PATH=/usr/lib64 cargo build --release

See https://github.com/KyleMayes/clang-sys#environment-variables for more options.

The features render and wayland enable the optional extensions wlc provides.

In that case WlcSurface, WlcSubSurface and GLES2Renderer should also not be send across threads, when using unsafe-stable.

A note on rust-wlc

rust-wlc has some short comings this crate tries to avoid. It was build without any parts of the original rust-wlc source code and may have its own problems, but it tries to deal with the following issues differently:

(In the following statements wlc refers to the original C Library and rust-wlc to the alternative wlc bindings)

• wlc does not transfer the ownership of views and output structs to the implementing compositor. Instead any view or output might be deallocated by the library after a view_destroyed/output_destroyed callback. rust-wlc does not model this relationship correctly in my opinion. See DESIGN.md to understand how this library models View and Output.
• rust-wlc lets you use extern functions and directly interfere with C-code. This implementation almost requires a global singleton and the usage of lazy_static. This crate provides you with a Trait to be used for you custom compositor and hides these implementation details.
• This crate provides a safer alternative to wlc's userdata API. It is still unsafe in some aspects and should be abstracted by any compositor implementation, but it is easier to handle.
• Exposes run loop functions.
• This crate implements most of wlc's render and wayland api's.
• rust-wlc is most likely better tested, as it has likely some more users and a simple mocking library (if I am correct). So please report any issues you may find.

Please note, that I do not try to compete with rust-wlc in anyway. I also respect the work they have done and their window manager way-cooler is certainly an interesting project. I just did not like their design decisions and decided to build my own wlc-bindings and my own window manager.