Once again there’s been a release of the “game engine meets display server meets multimedia framework” project, Arcan, and of its reference desktop environment Durden.
Among the many new engine feature this time around, we find: improved crash recovery, much improved support for Wayland clients, and initial support for OpenBSD. Among the DE features, we find window slicing and overlays, input multicasting, and LED controller profiles.
Refer to the full release announcement for more details and videos.
I hope this beats out wayland for a number of reasons for becoming the standard in GNU World.
This is orthogonal to wayland. Arcan may choose to not implement the wayland protocol, however it wouldn’t be able to display application windows like, say, firefox.This can replace kwin, mutter, e18…
Not exactly, but I deliberately don’t compete or upstream the backends I add to various applications (e.g. QEmu, SDL2, Xorg, libretro). For nitty gritty details, see:
http://github.com/letoram/arcan/wiki/Shmif
The summary is that Arcan is by design multi-process in a microkernel like architecture – for resilience, performance and security reasons. The IPC subsystem that ties it all together (i.e. Shmif) – is kept in lock step with the engine and there is no commitment towards ABI stability, that is why it is not a ‘protocol’ and hence not ‘an alternative’ or competition as such. The features in the IPC subsystem is a superset of what is needed for playing the part of a wayland “compositor”, and actually very close to parity with- and in some aspect beyond- what X offers.
You can also see this in action here:
https://youtu.be/ynbS4nfdpPg?t=31s
Edited 2017-09-27 16:05 UTC
Is shmif-tui at least API stable, if not ABI?
Yes for everything but the advanced stuff, and that’s not far away.
The two developments that are blocking:
1. a special build of the terminal emulator that uses the graphics/input backend in Arcan, allowing TUI API clients to run without the rest of the infrastructure, so you can use it in the same way as kmscon worked, or as a normal Xorg application.
2. completion of the Lua bindings for both the benefit of building a larger test suite, and being forced to rediscover the API from another language context.
Awesome to see OpenBSD support in the works!