"Currently, a Wayland compositor combines three primary functions into one. It must act as a display server, it must manage windows, and it must composite those windows together to be displayed on screen. The River project, which is about three years old now, splits this up. It's a display server and it's a compositor, but it doesn't do window management. Instead, it offers a documented window management protocol so that another, separate program can do the window management."
"In it, Freund introduced his River project, which he describes as "a non-monolithic Wayland compositor." River brings to Wayland the idea of a window manager as a separate program, and it already supports a list of ten different WMs that can work with it. Freund is a member of the core team of the Zig programming language and works on wlroots, modules for building Wayland compositors. He explained that with River, he "plans to change the Wayland architecture to make it more easy to experiment.""
River is a non-monolithic Wayland compositor that separates display server/compositor roles from window management by exposing a documented window management protocol. The compositor implements a simple state machine and handles display and composition, while external window manager programs handle arrangement and decorations. The protocol enabled rapid third-party development, producing at least nine independent window managers shortly after publication and support for ten WMs already exists. The design preserves X11-style decoration freedom, improves responsiveness by removing window-management overhead from display tasks, and aims to make Wayland experimentation easier.
Read at Theregister
Unable to calculate read time
Collection
[
|
...
]