An error that may occur during operation of this crate.

The future returned by the `send_request` method.

The future returned by the `wait_for_reply` function.

Either the X11 event or the clock hand request.

An implementation of `Display` that requires a mutable reference to use.

Always assume that we are blocking.

A wrapper around a [`Connection`] that buffers all of the I/O. System calls for I/O are expensive, while reading to and writing from memory is not. T

A self-contained request. Useful for futures.

An implementation of `Display` that can be used immutably through thread-unsafe cells.

The future returned by the `check_for_error` function.

A wrapper around [`SendRequest`] that immediately resolves the cookie.

A "suitable byte stream" where communication with the X11 server can occur. See the [module level documentation](index.html) for more details.

A sequence number indicating the state of a request.

A blocking interface to the X11 server. This interface can be used to do everything that [`DisplayBase`] can do, but it is also capable of blocking o

An interface to the X11 server, containing functionality that is neither inherently synchronous nor asynchronous. This trait is the supertrait for bo

Extension traits to allow for sending generic requests and replies.

A map of extension names to extension information.

Units of floating-point pixels.

The future returned by the `flush()` function.

The future returned by the `generate_xid` function.

The innards of the [`Error`] struct. Making this type not public allows us to change it without it being a breaking change.

A reply that can have more than one reply.

A wrapper around `std::sync::Mutex` when `parking_lot` is not enabled, and `parking_lot::Mutex` when it is.

A connection that can be derived from a parsed display name. This is the primary [`Connection`] type that is used in `breadx`, as it represents the m

A wrapper around a type that may be able to be poisoned if it runs an operation that may put it into an invalid state.

Assume that we are just polling for a reply or event.

Some internal data that needs to be fetched through another request.

A request that needs to be prefetched.

The raw reply.

The raw request. This structure essentially acts as a monomorphization of the [`Request`] trait. It contains all of the information needed to send th

The buffer used to store reads.

A wrapper around `std::sync::RwLock` when `parking_lot` is not enabled, and `parking_lot::RwLock` when it is.

The future returned by the `send_request_raw` function.

A variant of the [`UnixStream`] connection that uses `sendmsg` to send data and `recvmsg` to receive it. The main difference between this type and [`

Whether we should use a non-blocking strategy or a blocking strategy for waiting for events.

A `Display` that uses a mutex to coordinate access.

Future for the "synchronize" operation.

It is useful, for testing, to just have a `Connection` that reads and writes from internal buffers.

The future returned by `try_with()`.

The entire point of this module. Takes a function that spawns an iterator, and runs it on another thread.

A type that can be used in the "void" position.

The future returned by the `wait_for_event` function.

The future returned by the `wait_for_reply_raw` function.

A helper type for `SyncDisplay` that allows us to use `Waker`s to wake up the `SyncDisplay` when a lock is released. Basically uses a "thunder lock".

The buffer used to store writes.

The core of all of the `breadx` displays. This structure is configured such that all other `Display` implementors build around it.

An iterator that processes the contents of an XCB-XML file. This is the return type of [`read_xcb`] and [`read_xcb_from_file`]. It is intended that `