Trait breadx::display::DisplayBase[][src]

pub trait DisplayBase {
Show methods fn setup(&self) -> &StaticSetup;
fn default_screen_index(&self) -> usize;
fn next_request_number(&mut self) -> u64;
fn generate_xid(&mut self) -> Option<XID>;
fn add_pending_item(&mut self, req_id: u16, item: PendingItem);
fn get_pending_item(&mut self, req_id: u16) -> Option<PendingItem>;
fn take_pending_item(&mut self, req_id: u16) -> Option<PendingItem>;
fn has_pending_event(&self) -> bool;
fn push_event(&mut self, event: Event);
fn pop_event(&mut self) -> Option<Event>;
fn create_special_event_queue(&mut self, xid: XID);
fn push_special_event(
        &mut self,
        xid: XID,
        event: Event
    ) -> Result<(), Event>;
fn pop_special_event(&mut self, xid: XID) -> Option<Event>;
fn delete_special_event_queue(&mut self, xid: XID);
fn checked(&self) -> bool;
fn set_checked(&mut self, checked: bool);
fn bigreq_enabled(&self) -> bool;
fn max_request_len(&self) -> usize;
fn get_extension_opcode(&mut self, key: &[u8; 24]) -> Option<u8>;
fn set_extension_opcode(&mut self, key: [u8; 24], opcode: u8);
fn wm_protocols_atom(&self) -> Option<NonZeroU32>;
fn set_wm_protocols_atom(&mut self, a: NonZeroU32); fn add_pending_request(&mut self, req_id: u16, pereq: PendingRequest) { ... }
fn get_pending_request(&mut self, req_id: u16) -> Option<PendingRequest> { ... }
fn take_pending_request(&mut self, req_id: u16) -> Option<PendingRequest> { ... }
fn add_pending_reply(&mut self, req_id: u16, perep: PendingReply) { ... }
fn take_pending_reply(&mut self, req_id: u16) -> Option<PendingReply> { ... }
fn add_pending_error(&mut self, req_id: u16, err: BreadError) { ... }
fn check_for_pending_error(&mut self, req_id: u16) -> Result { ... }
fn screens(&self) -> &[StaticScreen]

Notable traits for &'_ [u8]

impl<'_> Read for &'_ [u8]impl<'_> Write for &'_ mut [u8]
{ ... }
fn default_screen(&self) -> &StaticScreen { ... }
fn default_root(&self) -> Window { ... }
fn default_white_pixel(&self) -> u32 { ... }
fn default_black_pixel(&self) -> u32 { ... }
fn default_visual_id(&self) -> Visualid { ... }
fn default_visual(&self) -> &Visualtype { ... }
fn default_colormap(&self) -> Colormap { ... }
fn visual_id_to_visual(&self, id: Visualid) -> Option<&Visualtype> { ... }
fn get_scanline_pad(&self, depth: u8) -> usize { ... }
fn depth_of_visual(&self, id: Visualid) -> Option<u8> { ... }
}
Expand description

This trait represents a connection to the X11 server. Most operations in breadx revolve around an object implementing this trait in some way, shape, or form.

Internally, this should act as a layer of abstraction over the inner Connection object that keeps track of the setup, outgoing and pending requests and replies, the event queue, et cetera. Orthodoxically, X11 usually takes place over a TCP stream or a Unix socket connection.

Upon its instantiation, the DisplayBase should send bytes to the server requesting the setup information, and then stores it for later use. This can be done via the establish convenience method provided by the Connection and AsyncConnection traits. Afterwards, it awaits commands from the programmer to send requests, receive replies or process events.

Objects implementing this trait should further implement Display and/or AsyncDisplay.

Usage

When writing a function that takes an object implementing a DisplayBase as a parameter, consider rewriting it to the form:

fn my_function<D: DisplayBase>(display: &mut D) { /* ... */ }

This allows you to change to another type of display easily without needing to go back and change the signature of all of your functions.

Required methods

Get the Setup object that defines the X11 connection.

The Setup object provides a litany of information regarding the X11 server, such as the server’s vendor, the visual formats, and the roots of the Screen windows. The implementor should store a Setup somewhere in the object, and return a reference to it for this function.

Get the default screen index.

The Setup contains a list of “roots”, and this object serves as an index into this array to determine which one to use as a default screen. This is usually provided by either the user or the name string.

Generate the next request number to be used to define a request.

The X server provides each request with a 64-bit number in order to identify its replies. This number starts at 1 and counts up for each request, eventually wrapping back to 0 at the end. The implementor should keep track of this running count.

Generate an XID within appropriate bounds. Returns None if our XIDs are exhausted.

The Setup contains information useful for building an XID generator. The implementation should build an appropriate XID generator and then use it in order to

Add a PendingItem to this display’s map.

The implementation is expected to keep a map matching PendingItems to their request sequences. This method inserts into that map.

Clone a PendingItem from this display’s map and return it. See add_pending_item for more information.

Remove a PendingItem from this display’s map. See add_pending_item for more information.

Tell if there are any items currently in the queue.

Push an event into this display’s event queue.

The display is expected to keep a queue of events that it receives whenever it runs wait or poll_wait. This is provided so the implementations for wait and poll_wait can add events to this internal queue.

Pop an event from this display’s event queue. See push_event for more information.

Create a new special event queue.

Some extensions, like present, may want to keep a different queue of events than the general event queue. To do this, it tells the server to tag the events with some XID, and then uses that XID to create the special event queue. Then, events tagged with this specific XID are sorted into the special event queue instead of the general one.

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.

Whether or not zero-length replies are checked.

When handling requests that do not have a reply (i.e. zero-length replies), there are two approaches. You can either simply ignore the request and return a defaulted reply (unchecked mode), or send a small request and poll the server until the request is replied to, in order to ensure that the server has already processed the original request (checked mode). Although unchecked mode is significantly faster, checked mode allows for more accurate error diagnostics.

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.

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.

The implementation is expected to keep a map of extension names to the opcodes of said extensions, as revealed by the server.

Set the opcode for an extension. See get_extension_opcode for more information.

Get the WM_PROTOCOLS atom, which we cache in the display.

WM_PROTOCOLS is used often by the display, so we cache it in order to ensure we don’t have to request it more than once.

Set the WM_PROTOCOLS atom. See wm_protocols_atom for more information.

Provided methods

Insert a pending request into this display. This simply wraps the PendingRequest into a PendingItem and then calls add_pending_item.

Get a pending request from this display. This calls get_pending_item and returns None if the object is not a pending request.

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.

Insert a pending reply into this display. This simply wraps the PendingRequest into a PendingItem and then calls add_pending_item.

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.

Insert a pending error into this display. This simply wraps the BreadError into a PendingItem and then calls add_pending_item.

Check this display for the pending error. This calls take_pending_item and returns Ok if the object if not an error.

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.

Implementations on Foreign Types

Implementors