|0.0.1-alpha1||Mar 29, 2023|
#16 in #compositor
38 downloads per month
Used in 2 crates
Fundamental types and traits for a wayland compositor
This crate provides the scaffolding for writing a wayland compositor. It defines the traits for per-client and server global contexts, and traits for implementing wayland objects. It also provides helper for implementing these traits.
Structure of a compositor
Let's break down a wayland compositor by looking at its data flow. (I used the word "data flow" loosely here.)
A wayland compositor starts by creating a socket and listening on it. Once a client connects to the socket, the compositor accepts the connection, and creates a new per-client context for it. The per-client context contains the object store, which will have a wl_display object already bound in it. The client can issue requests to objects in its object store, by referring to them with their object ID. The compositor handles these requests by calling the wayland interface implementations associated with the objects.
How this crate fits in
The traits in
objects defines the interface of wayland
objects. You can choose to implement wayland objects with them and the
RequestDispatch traits generated from the wayland protocol spec (See the
runa-wayland-protocols crate). Or you can also use the
crate which provides implementations for many of the wayland objects.
Client trait defines the interface of
a per-client context. See its documentation for more details. That trait
explains how most of the other stuffs fit together.
Server trait is responsible for
creating a new client context each time a new client connects. It also
provides access to the globals.