1 unstable release
0.0.1-alpha1 | Mar 29, 2023 |
---|
#14 in #object-id
25 downloads per month
Used in 2 crates
330KB
3.5K
SLoC
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
Function wayland_listener
and wayland_listener_auto
can be used to
create the socket for incoming connections.
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 runa-orbiter
crate which provides implementations for many of the wayland objects.
The 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.
The Server
trait is responsible for
creating a new client context each time a new client connects. It also
provides access to the globals.
Dependencies
~20–32MB
~521K SLoC