NetBSD ist standardmäßig auf den Fenstermanager CTWM umgestiegen und experimentiert mit Wayland

Projekt NetBSD gab bekannt zum Wechsel des standardmäßig im X11-Sitzung angebotenen Fenstermanagers von twm auf CTWM. CTWM ist ein Fork von twm, der 1992 entstanden ist und in Richtung eines leichten und vollständig anpassbaren Fenstermanagers entwickelt wurde, der die Anpassung des Designs und des Verhaltens nach eigenem Geschmack ermöglicht.

Der Fenstermanager twm wurde in den letzten 20 Jahren in NetBSD angeboten und wirkte unter modernen Bedingungen veraltet. Die negative Reaktion der Nutzer auf den standardmäßig angebotenen twm veranlasste die Entwickler, die Standardumgebung zu überdenken und einen funktionalereren Fenstermanager CTWM einzusetzen, um eine benutzerfreundliche Umgebung für Nutzer zu schaffen, die Erfahrung mit anderen Betriebssystemen haben.

CTWM unterstützt virtuelle Arbeitsflächen, wird aktiv weiterentwickelt und wird unter einer mit NetBSD kompatiblen Lizenz bereitgestellt. Zu den neu implementierten Funktionen auf Basis von CTWM gehören ein automatisch generiertes Anwendungsmenü, nützliche Tastenkombinationen für die vollständige Steuerung ohne Maus, die Anpassung für verschiedene Bildschirmauflösungen (einschließlich HiDPI nach der Hinzufügung großer Schriftarten) sowie die Möglichkeit, sowohl mit sehr langsamen als auch sehr schnellen Systemen mithilfe einer einzigen Konfigurationsdatei zu arbeiten.

Früher:

Ist geworden:

Zusätzlich wurde veröffentlicht Hinweis zum Stand des Projekts zur Implementierung eines Komposit-Servers in NetBSD swc basierend auf dem Wayland-Protokoll. Der Port ist derzeit noch nicht für den täglichen Gebrauch bereit, eignet sich jedoch schon für Experimente und das Ausführen von Anwendungen, die Qt5, GTK3 oder SDL2 verwenden. Es werden Probleme wie Inkompatibilitäten mit bestimmten Anwendungen, einschließlich Firefox, fehlende Unterstützung für den Start von X11-Anwendungen und die Möglichkeit, nur mit Intel-GPUs zu arbeiten, für die ein Treiber zum Wechseln von Videomodi auf Kernel-Ebene vorhanden ist, angeführt.

Zu den Schwierigkeiten bei der Portierung von Wayland nach NetBSD wird der hohe Anteil an betriebssystemspezifischem Code in den Komposit-Managern genannt, der für die Verwaltung von Bildschirm, Eingabe und Fenster verantwortlich ist. Wayland bietet keine fertigen Protokolle für Funktionen wie das Erstellen von Screenshots, die Sperrung des Bildschirms und das Fenster-Management und hinkt derzeit in Bereichen wie Portabilität, Modularität und Standardisierung hinter dem X-Server hinterher.

Zusätzliche Funktionen werden durch den kompositorischen Manager oder durch die Definition von Erweiterungen zu Protokollen realisiert. Der Referenz-Kompositionsserver Weston ist stark an die API des Linux-Kerns gebunden. Zum Beispiel erfordert die Bindung an den Multiplexing-Mechanismus epoll eine Überarbeitung zur Unterstützung von kqueue. Patches zur Verwendung von kqueue wurden bereits von den Entwicklern der BSD-Systeme vorbereitet, sind jedoch noch nicht in den Hauptbestand aufgenommen worden.

Der Code des Referenz-Kompositionsservers wurde ursprünglich nur mit Blick auf Linux geschrieben und berücksichtigt nicht die Besonderheiten anderer Systeme (zum Beispiel wird im Code «#include » verwendet und es besteht eine Abhängigkeit von libinput). In FreeBSD gibt es eine Klon-API für die Eingabe von Linux, während in NetBSD eine grundsätzlich andere API für die Eingabeverwaltung — wscons — verwendet wird. Derzeit wurde die Unterstützung für wscons bereits in swc hinzugefügt und ist für die Übertragung auf andere Kompositionsmanager geplant.

Vertreter von NetBSD beabsichtigen, die Entwickler von Wayland davon zu überzeugen, keine feste Bindung an epoll zu verwenden, sondern auf eine universelle Schicht wie libevent umzusteigen. Zu den geplanten Arbeiten zählt auch die Aktualisierung des DRM/KMS-Stacks des NetBSD-Kerns und der Grafiktreiber, unter anderem durch die Portierung von Code aus dem Linux-Kern sowie die Hinzufügung der Unterstützung für atomare Wechsel von Video Modi, neue Versionen von DRM und die Glamor-API (um X11-Anwendungen unter xwayland auszuführen). Es ist geplant, Unterstützung für Framebuffer in den auf Wayland basierenden Kompositionsserver hinzuzufügen.

Quelle: opennet.ru