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.