Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
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 *;
;
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 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 modelsView
andOutput
. - rust-wlc lets you use
extern
functions and directly interfere with C-code. This implementation almost requires a global singleton and the usage oflazy_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.