tiny-xlib

一组绑定到 Xlib 库的绑定。

目前处理 Xlib 的主要库是 x11-dl 库。然而，存在三个主要问题。

1. 你不应该在 2023 年使用 Xlib。 Xlib 是过时的代码，即使这样也不足以说明它锁定的 API 决策有多糟糕。它有一个全局的错误钩子，线程安全性一团糟，而且存在许多不稳定性，几乎像瑞士奶酪一样。你不应该使用 Xlib。如果你 必须 使用 Xlib，你应该只使用更稳定的 XCB 库，或者更理想的是像 x11rb 这样的东西。然后，你使用 Display 指针进行任何过时的 API，然后使用 XCB 或 x11rb 做其他所有事情。是的，我刚刚把 GLX 称为一个过时的 API。现在是 2020 年代。除了旧机器之外，Vulkan 和 wgpu 到处都是。更不用说，它们支持 XCB。

2. 即使你成功使用 x11-dl 而没有遇到遗留API的问题，它也是一个庞大的crate。 Xlib 提供了很多函数，其中大部分在21世纪都是不必要的。即使你不使用这些函数而只坚持使用 XCB，你仍然要为其付费。使用 x11-dl 的二进制文件需要为其二进制和内存空间分配大量的空间。即使是在发布构建中，我也记录了 x11-dl 占用了高达七个百分比的二进制空间。

3. 全局错误处理。 Xlib 有一个单独的全局错误钩子。这让人联想到Unix信号处理API，因为它使得创建高度模块化的程序变得困难，因为这些程序会在错误处理程序之间相互竞争。然而，与信号处理API不同，没有方法可以告诉你是否在替换现有的错误钩子。

tiny-xlib 旨在解决所有这些问题。它提供了一个围绕 Xlib 的安全API，有利于将其传递给 XCB API和遗留的 Xlib API。该库只导入绝对必要的函数。此外，它还提供了一个用于以安全、模块化方式处理错误的通用API。

功能

• 围绕 Xlib 的安全API。请参阅 Display 结构。
• 最小依赖集。
• 实现了 AsRawXcbConnection，允许它与 XCB API一起使用。
• 模块化错误处理。

非功能特性

• 除了打开 Display 和处理错误之外的所有API。如果这个库不支持某些功能，那可能是故意的。你应该使用 XCB 或 x11rb。这包括
• 窗口管理。
• 除了 Xlib-xcb 之外的所有扩展。
• IME处理。
• 硬件渲染。

示例

use as_raw_xcb_connection::AsRawXcbConnection;
use tiny_xlib::Display;

use x11rb::connection::Connection;
use x11rb::xcb_ffi::XCBConnection;

// Open a display.
let display = Display::new(None)?;

// Get the XCB connection.
let xcb_conn = display.as_raw_xcb_connection();

// Use that pointer to create a new XCB connection.
let xcb_conn = unsafe {
    XCBConnection::from_raw_xcb_connection(xcb_conn.cast(), false)?
};

// Register a handler for X11 errors.
tiny_xlib::register_error_handler(Box::new(|_, error| {
    println!("X11 error: {:?}", error);
    false
}));

// Do whatever you want with the XCB connection.
loop {
    println!("Event: {:?}", xcb_conn.wait_for_event()?);
}

许可证

许可为以下之一

• Apache许可证版本2.0 (LICENSE-APACHE 或 https://www.apache.org/licenses/LICENSE-2.0)
• MIT许可证 (LICENSE-MIT 或 https://opensource.org/licenses/MIT)
• Zlib许可证 (LICENSE-ZLIB 或 https://opensource.org/licenses/Zlib)

任选其一。

贡献

除非你明确声明，否则任何有意提交以包含在你所定义的工作中的贡献，根据Apache-2.0许可证，应如上所述双重许可，不附加任何额外条款或条件。