Feel free to open issues for any problems or questions you might have. A comparison with some other Rust X11 libraries is available in an extra document.
This crate uses a code generator that is implemented in Python. As such, you need to have Python available to build this crate.
The code generator uses the X11 XML description from xcb-proto. When the
vendor-xcb-proto is enabled, which it is by default, a copy of xcb-proto that
comes with the source code is used.
When that feature is disabled, pkg-config is used to find xcb-proto. In a
nutshell, if you can run pkg-config --modversion xcb-proto successfully, you
should be fine. On Debian, the necessary packages are called pkg-config,
xcb-proto, and python-xcbgen. I hope that other distros use similarly
obvious naming.
No. If you have so many X11 connections that this would matter, you are doing something wrong. Also, it encourages people to write high-latency code instead of sending multiple requests and only afterwards wait for the replies.
The following features are enabled by default:
vendor-xcb-proto: Use our own copy of xcb-proto. Without this feature,
pkg-config is used to find xcb-proto.allow-unsafe-code: Without this feature, forbid(unsafe_code) forbids all
unsafe code. With this feature, XCBConnection and FD passing become
available.The full X11 protocol is supported by this library. All extensions that are
available in xcb-proto can be used and even FD
passing with the server is supported.
The changelog is available in a separate file.
Licensed under either of
at your option.
The subdirectory xcbproto-1.13-6-ge79f6b0 contains a vendored copy of the package of the same name. It is covered by the MIT license. See xcbproto-1.13-6-ge79f6b0/COPYING for details.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.