# [wlc](https://github.com/Cloudef/wlc) Bindings for Rust [](https://travis-ci.org/Drakulix/wlc.rs) [](https://crates.io/crates/wlc) [](https://crates.io/crates/wlc) [](https://github.com/Aaronepower/tokei)
Completely safe and idiomatic bindings to the wayland compositor library.
## [Documentation](https://drakulix.github.io/wlc.rs)
## Example
```rust
// 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 `struct`s 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](https://github.com/Cloudef/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](https://github.com/Immington-Industries/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](https://github.com/Drakulix/wlc.rs/tree/master/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](https://github.com/Drakulix/fireplace).