Event

<p>Current Wayland compositor implementations handle window management and compositing in the same monolithic process. Wayland does not however force this architecture.</p> <p>I am the author of the <a href="https://isaacfreund.com/software/river/">river</a> Wayland compositor. It supports a custom Wayland protocol, <a href="https://isaacfreund.com/docs/wayland/river-window-management-v1/">river-window-management-v1</a>, which allows a special "window manager" Wayland client to handle all window management policy, draw server side decorations, setup keybindings, and more.</p> <p>My goal with this work is to make hacking on Wayland window managers significantly more accessible and promote ecosystem diversity. There is already a <a href="https://codeberg.org/river/wiki/src/branch/main/pages/wm-list.md">growing list of window managers</a> developed for the new protocol.</p> <p>This talk will give an overview of this new protocol and the advantages/disadvantages of separating the Wayland compositor and window manager. There will also be a brief demo.</p>