Projekt NetBSD o zmianie domyślnego menedżera okien w sesji X11 na na . CTWM to forka twm, która powstała w 1992 roku, rozwijana w kierunku stworzenia lekkiego i w pełni konfigurowalnego menedżera okien, umożliwiającego dostosowanie wyglądu i zachowania według własnych upodobań.
Menedżer okien twm był oferowany w NetBSD przez ostatnie 20 lat i w dzisiejszych warunkach wyglądał archaicznie. Negatywna reakcja użytkowników na domyślnie proponowany twm skłoniła programistów do przemyślenia powłoki domyślnej i wprowadzenia bardziej funkcjonalnego menedżera okien CTWM, aby stworzyć środowisko przyjazne dla użytkowników mających doświadczenie w innych systemach operacyjnych.
CTWM wspiera wirtualne pulpity, aktywnie się rozwija i jest dostarczany na licencji zgodnej z NetBSD. Do nowych możliwości wdrożonych na bazie CTWM należy automatycznie generowane menu aplikacji, przydatne skróty klawiszowe umożliwiające pełne zarządzanie bez myszy, dostosowanie do pracy z różnymi rozdzielczościami ekranu (w tym HiDPI po dodaniu dużych czcionek), możliwość wsparcia zarówno dla bardzo wolnych, jak i bardzo szybkich systemów przy pomocy jednego pliku konfiguracyjnego.
Było:
Stało się:
Dodatkowo notatka o stanie projektu dostosowania serwera kompozytowego do pracy w NetBSD na bazie protokołu Wayland. Port na razie nie jest gotowy do codziennego użytku, ale już nadaje się do eksperymentów i uruchamiania aplikacji używających Qt5, GTK3 lub SDL2. Problemem jest brak kompatybilności z niektórymi aplikacjami, w tym Firefoxem, brak wsparcia dla uruchamiania aplikacji X11, a także możliwość pracy tylko z GPU Intel, dla których istnieje sterownik do przełączania trybów wideo na poziomie jądra.
Wśród cech Waylanda, które utrudniają portowanie do NetBSD, wymienia się dużą ilość specyficznego dla systemu kodu w menedżerach kompozytowych, odpowiedzialnych za zarządzanie ekranem, wejściem i oknami. Wayland nie zapewnia gotowych protokołów dla takich funkcji jak tworzenie zrzutów ekranu, blokowanie ekranu i zarządzanie oknami, a obecnie pozostaje w tyle za serwerem X w takich obszarach, jak przenośność, modularność i standaryzacja.
Dodatkowe możliwości są realizowane przez menedżera kompozytowego lub poprzez definiowanie rozszerzeń do protokołów. Referencyjny serwer kompozytowy Weston jest mocno związany z API jądra Linux. Na przykład, powiązanie z mechanizmem wielokrotnego dostępu do wejścia/wyjścia epoll wymaga przeróbki, aby wspierać kqueue. Łatki do używania kqueue zostały już przygotowane przez programistów systemów BSD, ale jeszcze nie zostały przyjęte do głównego składu.
Kod referencyjnego serwera kompozytowego został pierwotnie napisany z myślą tylko o Linux i nie uwzględnia specyfiki innych systemów (na przykład w kodzie używane jest „#include ” oraz zależność od libinput). W FreeBSD wdrożono klon API wejścia Linux, ale w NetBSD stosuje się zasadniczo inne API do zarządzania wejściem — wscons. W chwili obecnej wsparcie dla wscons zostało już dodane do swc i jest zaplanowane do przeniesienia do innych menedżerów kompozytowych.
Przedstawiciele NetBSD zamierzają przekonać programistów Wayland do nieużywania sztywnego powiązania z epoll i przejścia na uniwersalną warstwę, taką jak libevent. W planowanych pracach wyróżnia się również aktualizacja stosu DRM/KMS jądra NetBSD oraz sterowników graficznych, w tym portowanie kodu z jądra Linux, a także dodanie wsparcia dla atomowego przełączania trybów wideo, nowych wersji DRM oraz API Glamor (do uruchamiania aplikacji X11 pod kontrolą xwayland). Do serwera kompozytowego opartego na Wayland planuje się dodać wsparcie dla framebufferów.
Źródło: opennet.ru
