Die Version 0.4.0 des Kompositormanagers River wurde vorgestellt. Im Gegensatz zu anderen Kompositormanagern, die auf dem Wayland-Protokoll basieren, verwendet er eine modulare Architektur, bei der der Fensterverwalter als separates Programm ausgegliedert ist. In River sind Fensterverwalter plug-in-fÀhig, sodass Benutzer aus einer Auswahl wÀhlen können. Der Code des Projekts ist in der Programmiersprache Zig geschrieben und wird unter der GPLv3-Lizenz veröffentlicht.
River kann sowohl in verschachtelten Sitzungen ausgefĂŒhrt werden, die ĂŒber anderen X11- und Wayland-Servern laufen, als auch ohne Zwischenschichten, indem KMS/DRM-Treiber fĂŒr die Ausgabe verwendet werden. Um die FunktionalitĂ€t von Kompositoren und Fensterverwaltern zu trennen, wird vom Projekt das Wayland-Protokoll river-window-management-v1 entwickelt. Funktionen wie Fensterdekoration, Eingabefokusverwaltung, Pointerkontrolle, Tastenkombinationen, sowie die Position und GröĂe von Fenstern werden in den Fensterverwalter ausgelagert.
Es ist möglich, Fenster-Manager dynamisch zu wechseln, ohne die Sitzung zu unterbrechen. Zur Auswahl stehen 16 kompatible Fenster-Manager mit River, darunter mosaikartige Fenster-Manager im DWM- oder xmonad-Stil, Emacs-Ă€hnliche im EXWM-Stil, klassische stapelbare und solche, die auf einem scrollbaren Band basieren. FĂŒr die AusfĂŒhrung von X11-Anwendungen wird die Nutzung von Xwayland unterstĂŒtzt.
Unter den GrĂŒnden fĂŒr die Trennung von Komposit- und Fenster-Managern werden genannt: die Senkung der HĂŒrde fĂŒr die Entwicklung von Fenster-Managern; die Möglichkeit, Fenster-Manager in Hochsprachen mit Garbage Collection zu implementieren, die die Leistung des Komposit-Managers nicht beeintrĂ€chtigen; die Möglichkeit des Hot-Swap von Fenster-Managern ohne Neustart des Komposit-Managers Server und laufender grafischer Programme; die Vereinfachung von Experimenten im Zusammenhang mit dem Design von Fenster-Managern.
Aus den EinschrĂ€nkungen des Protokolls river-window-management-v1 geht hervor, dass die FunktionalitĂ€t auf 2D-BĂŒrooperationen beschrĂ€nkt ist. Beispielsweise werden keine komplexen Effekte und 3D-Interfaces fĂŒr Virtual-Reality-Systeme unterstĂŒtzt. Die Effekte beschrĂ€nken sich derzeit auf einfache Animationen, jedoch sind in Zukunft komplexere Effekte durch den Einsatz von Shadern geplant. 
Quelle: opennet.ru
