Struct breadx::display::BasicDisplay [−][src]
pub struct BasicDisplay<Conn> { /* fields omitted */ }Expand description
An implementor of Display and AsyncDisplay that requires &mut access in order to use.
This is the standard implementation of a display for the X11 protocol. In addition to storing the connection to the server and the setup information received from the server, it contains the event queues, pending item map, and provides XIDs and sequence numbers.
It is recommended to create an instance of this object via DisplayConnection::create(), since that
function uses the system’s variables in order to connect to the X11 server. However, niche use cases who need
to communicate with the X server in other ways should use [BasicDisplay::from_connection].
Connection Poisoning
If a panic occurs while sending/receiving along the connection, or if a future involving sending/receiving
across the connection is dropped, the connection may be “poisoned”. Attempting to use the connection after
it is poisoned will result in a panic, since the current state of the BasicDisplay is invalid and will
result in invalid communications with the X11 server. The exact semantics of what, exactly, will cause a
connection poisoning are not well defined at the moment. However, the connection should never be poisoned
during normal operation of the BasicDisplay.
Mutability
BasicDisplay requires an &mut reference for most operations, including sending and receiving requests and
replies. Although this “inherited mutability”, as we call it, may be convenient for architectures of programs
where multiple objects require access to the X server, it allows the connection to prevent undefined
behavior from occurring. To quote the rust std documentation for
std::cell:
The more common inherited mutability, where one must have unique access to mutate a value, is one of the key language elements that enables Rust to reason strongly about pointer aliasing, statically preventing crash bugs. Because of that, inherited mutability is preferred, and interior mutability is something of a last resort.
That being said, the CellDisplay object is preferred over using RefCell<BasicDisplay>, since it uses
several different cell types in order to reduce reentrant panics. However, using SyncDisplay instead of
Mutex<BasicDisplay> may not be preferred depending on your use case. See the documentation for
SyncDisplay for more information.
Implementations
Establishes this display using an inner connection type. This receives setup information from the server on the other side of the connection in order to populate the display.
In order to produce the Setup, from_connection sends a SetupRequest object across the provided
connection. This SetupRequest is populated with the AuthInfo provided by either the user, or the
file specified by the XAUTHORITY environment variable if the auth_info parameter is None. Once the
Setup has been received, it is stored in the BasicDisplay and the BasicDisplay is considered valid.
Finally, default_screen is used to dictate the default screen this display uses.
In addition, this function also tries to establish bigreq support, and if it does it enables the
corresponding variables in the `BasicDisplay.
Errors
If the server returns error code 0, this function will return BreadError::FailedToConnect, indicating
that the server refused our connection. If the server returns error code 2, this function will return
BreadError::FailedToAuthorize, indicating that the AuthInfo provided either by the user or the
“XAUTHORITY” is invalid. This function may also return an IO error if a system error occurs while
communicating with the server.
In addition, this function may also return BreadError::BadObjectRead if the Setup provided by the
server is invalid, but this will likely never occur unless a malicious X11 server is used.
Example
use breadx::display::BasicDisplay; use std::net::TcpStream; let server = TcpStream::connect("127.0.0.1:60000")?; let conn = BasicDisplay::from_connection(server, 0, None)?;
Establishes this display using an inner connection type. This receives setup information from the server on the other side of the connection in order to populate the display. This method uses async types in order to ensure that the operation is non-blocking.
See BasicDisplay::from_connection for more information.
Example
use async_io::Async; use blocking::unblock; use breadx::display::BasicDisplay; use std::net::TcpStream; let server = blocking::unblock(|| TcpStream::connect("127.0.0.1:60000")).await?; let server = Async::new(server)?; let conn = BasicDisplay::from_connection_async(server, 0, None).await?;
Create a new connection to the X server, given an optional name and authorization information.
This function instantiates a new NameConnection using either the name specification string passed
by the user, or the environment variable “DISPLAY” if the name parameter is None. The
NameConnection is either a TCP stream connected to port 60000 + X on the host, where X is the
display number, or a Unix socket connection to one of the X11 system sockets.
Once the NameConnection is created, it is passed into BasicDisplay::from_connection method to
establish the BasicDisplay.
This is the recommended way to create a BasicDisplay object, since most system running an X11 server
expect the user to use the “DISPLAY” variable in order to connect to it. from_connection should only
be used for niche use cases.
Errors
In addition to the errors that from_connection can return, this method may return
BreadError::UnableToParseConnection if the name string is improperly formatted, or an IO error if a
system error occurs while trying to connect to the server.
Example
Connect to the default X11 server, as specified by the environment variables.
use breadx::DisplayConnection; let conn = DisplayConnection::create(None, None)?;
Connect to the server on display 3, using the authorization info read from a file.
use breadx::{AuthInfo, DisplayConnection}; use std::fs::File; let mut file = File::open("my_auth_info.txt")?; let mut auth_info = AuthInfo::from_stream(&mut file).expect("AuthInfo not found"); let conn = DisplayConnection::create(Some(":3".into()), Some(auth_info.remove(0)))?;
Trait Implementations
Poll the current status of waiting for more input. There is no default implementation; the buffering
strategy depends on the implementor. If this is called after a Poll::Ready is returned, it is assumed
that the user wants to wait again. Read more
fn begin_send_request_raw(
&mut self,
req: RequestInfo,
_cx: &mut Context<'_>
) -> PollOr<(), RequestInfo>
fn begin_send_request_raw(
&mut self,
req: RequestInfo,
_cx: &mut Context<'_>
) -> PollOr<(), RequestInfo>Begin sending a raw request to the server. In order to poll the status of this operation, use the
poll_send_request_raw function. Read more
Send a request across the connection, given the monomorphized request info. Read more
Synchronize this display, ensuring that all data sent across it has been replied to. Read more
Resolve for a request, returning only the raw data of the reply. The default implementation assumes that the reply is not zero-sized. Read more
Wait for an event to be sent from the X server. Read more
Get the Setup object that defines the X11 connection. Read more
Get the default screen index. Read more
Generate the next request number to be used to define a request. Read more
Tell if there are any items currently in the queue.
Push an event into this display’s event queue. Read more
Pop an event from this display’s event queue. See push_event for more information.
Generate an XID within appropriate bounds. Returns None if our XIDs are exhausted. Read more
Add a PendingItem to this display’s map. Read more
Clone a PendingItem from this display’s map and return it. See add_pending_item for more
information. Read more
Remove a PendingItem from this display’s map. See add_pending_item for more information.
Create a new special event queue. Read more
Push an event into the special event queue. See create_special_event_queue for more information.
Pop an event from the special event queue. See create_special_event_queue for more information.
Delete a special event queue. See create_special_event_queue for more information.
Set whether or not zero-length replies are checked. See checked for more information.
Whether or not this display uses the bigreq extension, whereas requests consisting of over
262140 bytes are allowed to be sent over the connection. Read more
The current maximum request length. This is the maximum number of bytes the server can handle at a time.
Get the opcode for an extension. Read more
Set the opcode for an extension. See get_extension_opcode for more information.
Get the WM_PROTOCOLS atom, which we cache in the display. Read more
Set the WM_PROTOCOLS atom. See wm_protocols_atom for more information.
Insert a pending request into this display. This simply wraps the PendingRequest into a PendingItem
and then calls add_pending_item. Read more
Get a pending request from this display. This calls get_pending_item and returns None if the
object is not a pending request. Read more
Take a pending request from this display. This calls take_pending_item, inserting the object back into
the map if it is not a request. Read more
Insert a pending reply into this display. This simply wraps the PendingRequest into a PendingItem
and then calls add_pending_item. Read more
Take a pending reply from this display. This calls take_pending_item, inserting the object back into
the map if it is not a reply. Read more
Insert a pending error into this display. This simply wraps the BreadError into a PendingItem
and then calls add_pending_item. Read more
Check this display for the pending error. This calls take_pending_item and returns Ok if the object
if not an error. Read more
Get the list of screens in this display.
Get the default screen in this display.
Get the default root for this display.
Get the default pixel used for the white color.
Get the default pixel used for the black color.
Get the default visual ID for the screen.
Get the default visual for the default screen.
Get the colormap for the default screen.
Get a visual type from a visual ID.
Get the scanline pad for a certain depth.
Get the depth of the specified visual ID.
Convert a BasicDisplay into a CellDisplay.
Auto Trait Implementations
impl<Conn> !RefUnwindSafe for BasicDisplay<Conn>impl<Conn> Send for BasicDisplay<Conn> where
Conn: Send, impl<Conn> Sync for BasicDisplay<Conn> where
Conn: Sync, impl<Conn> Unpin for BasicDisplay<Conn> where
Conn: Unpin, impl<Conn> !UnwindSafe for BasicDisplay<Conn>Blanket Implementations
pub fn wait_async(&mut Self) -> WaitFuture<'_, D>ⓘNotable traits for WaitFuture<'a, D>
impl<'a, D: AsyncDisplay + ?Sized> Future for WaitFuture<'a, D> type Output = Result;
pub fn wait_async(&mut Self) -> WaitFuture<'_, D>ⓘNotable traits for WaitFuture<'a, D>
impl<'a, D: AsyncDisplay + ?Sized> Future for WaitFuture<'a, D> type Output = Result;Wait until we recieve data. Read more
pub fn send_request_raw_async(
&mut Self,
RequestInfo
) -> SendRequestRawFuture<'_, D>ⓘNotable traits for SendRequestRawFuture<'a, D>
impl<'a, D: AsyncDisplay + ?Sized> Future for SendRequestRawFuture<'a, D> type Output = Result<u16>;
pub fn send_request_raw_async(
&mut Self,
RequestInfo
) -> SendRequestRawFuture<'_, D>ⓘNotable traits for SendRequestRawFuture<'a, D>
impl<'a, D: AsyncDisplay + ?Sized> Future for SendRequestRawFuture<'a, D> type Output = Result<u16>;Send a raw request to the server. Read more
pub fn send_request_async<R>(&mut Self, R) -> SendRequestFuture<'_, D, R>ⓘNotable traits for SendRequestFuture<'a, D, R>
impl<'a, D: AsyncDisplay + ?Sized, R: Request + Unpin> Future for SendRequestFuture<'a, D, R> type Output = Result<RequestCookie<R>>; where
R: Request,
pub fn send_request_async<R>(&mut Self, R) -> SendRequestFuture<'_, D, R>ⓘNotable traits for SendRequestFuture<'a, D, R>
impl<'a, D: AsyncDisplay + ?Sized, R: Request + Unpin> Future for SendRequestFuture<'a, D, R> type Output = Result<RequestCookie<R>>; where
R: Request, Send a request to the server. This is the async equivalent of the DisplayExt::send_request function.
See that function for more information on what this is expected to do. Read more
pub fn resolve_request_async<R>(
&mut Self,
RequestCookie<R>
) -> ResolveRequestFuture<'_, D, R>ⓘNotable traits for ResolveRequestFuture<'a, D, R>
impl<'a, D: AsyncDisplay + ?Sized, R: Request> Future for ResolveRequestFuture<'a, D, R> where
R::Reply: Default, type Output = Result<R::Reply>; where
R: Request,
<R as Request>::Reply: Default,
pub fn resolve_request_async<R>(
&mut Self,
RequestCookie<R>
) -> ResolveRequestFuture<'_, D, R>ⓘNotable traits for ResolveRequestFuture<'a, D, R>
impl<'a, D: AsyncDisplay + ?Sized, R: Request> Future for ResolveRequestFuture<'a, D, R> where
R::Reply: Default, type Output = Result<R::Reply>; where
R: Request,
<R as Request>::Reply: Default, Resolve a request that we sent to the server. This is the async equivalent of the
DisplayExt::resolve_request function. See that function for more information on what this is expected
to do. Read more
pub fn synchronize_async(&mut Self) -> SynchronizeFuture<'_, D>ⓘNotable traits for SynchronizeFuture<'a, D>
impl<'a, D: AsyncDisplay + ?Sized> Future for SynchronizeFuture<'a, D> type Output = Result;
pub fn synchronize_async(&mut Self) -> SynchronizeFuture<'_, D>ⓘNotable traits for SynchronizeFuture<'a, D>
impl<'a, D: AsyncDisplay + ?Sized> Future for SynchronizeFuture<'a, D> type Output = Result;Synchronize this display so that every request that has been sent is resolved. This is the async
equivalent of the Display::synchronize function. See that function for more information on what this
is expected to do. Read more
pub fn resolve_request_raw_async(
&mut Self,
u16
) -> WaitLoopFuture<'_, D, ResolveRequestRawHandler>
pub fn resolve_request_raw_async(
&mut Self,
u16
) -> WaitLoopFuture<'_, D, ResolveRequestRawHandler>Resolve for a raw request. This is the async equivalent of the Display::resolve_request_raw
function. See that function for more information on what this is expected to do. Read more
Wait for an event to be sent from the X server. This is the async equivalent of the
Display::wait_for_event function. See that function for more information on what this is expected
to do. Read more
pub fn wait_for_special_event_async(
&mut Self,
u32
) -> WaitLoopFuture<'_, D, WaitForSpecialEventHandler>
pub fn wait_for_special_event_async(
&mut Self,
u32
) -> WaitLoopFuture<'_, D, WaitForSpecialEventHandler>Wait for a special event to be sent from the X server. This is the async equivalent of the
Display::wait_for_special_event function. See that function for more information on what this is
expected to do. Read more
pub fn exchange_request_async<R>(
&mut Self,
R
) -> ExchangeRequestFuture<'_, D, R>ⓘNotable traits for ExchangeRequestFuture<'a, D, R>
impl<'a, D: AsyncDisplay + ?Sized, R: Request + Unpin + 'a> Future for ExchangeRequestFuture<'a, D, R> where
R::Reply: Default + Unpin, type Output = Result<R::Reply>; where
R: Request,
pub fn exchange_request_async<R>(
&mut Self,
R
) -> ExchangeRequestFuture<'_, D, R>ⓘNotable traits for ExchangeRequestFuture<'a, D, R>
impl<'a, D: AsyncDisplay + ?Sized, R: Request + Unpin + 'a> Future for ExchangeRequestFuture<'a, D, R> where
R::Reply: Default + Unpin, type Output = Result<R::Reply>; where
R: Request, Send a request and wait for a reply back. This is the async equivalent of the
DisplayExt::exchange_request function. See that function for more information on what this is
expected to do. Read more
pub fn exchange_xid_async<R, U, F>(
&mut Self,
F
) -> ExchangeXidFuture<'_, D, R, U, F>ⓘ where
R: Request,
U: XidType + Unpin,
F: FnOnce(U) -> R,
pub fn exchange_xid_async<R, U, F>(
&mut Self,
F
) -> ExchangeXidFuture<'_, D, R, U, F>ⓘ where
R: Request,
U: XidType + Unpin,
F: FnOnce(U) -> R, Send a no-op request to the server, but resolve for an XID. This is similar to exchange_request_async,
but generates an XID before beginning the request send. This is largely a convenience wrapper. Read more
Mutably borrows from an owned value. Read more
Send a request to the server. Read more
pub fn resolve_request<R>(
&mut Self,
RequestCookie<R>
) -> Result<<R as Request>::Reply, BreadError> where
R: Request,
<R as Request>::Reply: Default,
pub fn resolve_request<R>(
&mut Self,
RequestCookie<R>
) -> Result<<R as Request>::Reply, BreadError> where
R: Request,
<R as Request>::Reply: Default, Resolve a request that we sent to the server. Read more