Crates.io | wlc-with_elogind |
lib.rs | wlc-with_elogind |
version | 2.0.1 |
source | src |
created_at | 2017-12-26 14:29:37.154613 |
updated_at | 2017-12-26 14:29:37.154613 |
description | Safe Bindings for Cloudef's wlc (Wayland Compositor C-Library) |
homepage | |
repository | https://github.com/Honey-Be/wlc.rs |
max_upload_size | |
id | 44454 |
size | 149,678 |
Completely safe and idiomatic bindings to the wayland compositor library.
// 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()
}
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
.
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)
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
.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.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.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.