1 stable release
Uses old Rust 2015
2.0.1 | Dec 26, 2017 |
---|
#1227 in GUI
135KB
3K
SLoC
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 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.
Dependencies
~2–4.5MB
~96K SLoC