NetBSD Project the change of the default window manager in the X11 session from to . CTWM is a fork of twm that branched off in 1992 and has been developed towards creating a lightweight and fully customizable window manager that allows users to change its appearance and behavior according to their preferences.
The twm window manager has been offered in NetBSD for the last 20 years and seemed outdated under modern conditions. The negative reactions of users to the default twm prompted developers to reconsider the default shell and use a more functional window manager, CTWM, to create an environment friendly to users with experience in other operating systems.
CTWM supports virtual desktops, is actively developed, and is distributed under a license compatible with NetBSD. Notable features of CTWM include an automatically generated application menu, useful keyboard shortcuts for full control without a mouse, adaptation for various screen resolutions (including HiDPI after incorporating larger fonts), and the ability to support both very slow and very fast systems with a single configuration file.
Previously:
Now:
Additional status note on the project to ensure the operation of the composite server in NetBSD based on the Wayland protocol. The port is not yet ready for everyday use but is already suitable for experimentation and running applications that use Qt5, GTK3, or SDL2. Issues include incompatibility with some applications, including Firefox, lack of support for running X11 applications, and operation only with Intel GPUs for which there is a driver to switch video modes at the kernel level.
Among the features of Wayland that complicate porting to NetBSD is the presence of a large amount of OS-specific code in composite managers responsible for screen management, input, and window management. Wayland does not provide ready-made protocols for capabilities such as taking screenshots, locking the screen, and window management, and it currently lags behind the X server in areas such as portability, modularity, and standardization.
Additional capabilities are implemented by the composite manager or through the definition of extensions to the protocols. The reference composite server Weston is heavily tied to the Linux kernel API. For instance, the integration with the input-output multiplexing mechanism epoll requires reworking to support kqueue. Patches for using kqueue have already been prepared by the BSD systems developers but have not yet been accepted into the mainline.
The code of the reference composite server was initially written with a focus solely on Linux and does not account for the specifics of other systems (for example, the code uses "#include " and has a dependency on libinput). FreeBSD implements a clone of the Linux input API, but NetBSD uses a fundamentally different API for input management — wscons. Currently, support for wscons has already been added to swc and is scheduled for migration to other composite managers.
Representatives from NetBSD aim to persuade the Wayland developers not to use a hard binding to epoll, but to transition to a universal layer such as libevent. Planned work also includes updating the DRM/KMS stack of the NetBSD kernel and graphic drivers, including porting code from the Linux kernel, as well as adding support for atomic video mode switching, new versions of DRM, and the Glamor API (for running X11 applications under xwayland). Support for framebuffers is planned to be added to the Wayland-based composite server.
Source: opennet.ru
