Recently I started implementing Wayland compatibility layer that allow to run Wayland based toolkits and applications such as GTK 3-4, potentially Chromium and Firefox. Unlike regular Wayland compositor, it have no server process and implementation is loaded as add-on of Wayland client process. Direct function calls are used instead of sockets. Approach is similar to Xlibe.
Compatibility layer use modified
libwayland code with stripped socket related logic added add-on mechanism. It provides API and ABI compatible
libwayland-client.so library that allows to run Wayland applications without changes. Wayland server is implemented as add-on “wayland-server-inproc.so” (Wayland in-process server) that are loaded when establishing connection. Wayland in-proc server maps Wayland protocol calls into Haiku API, for example
wl_surface_commit is mapped to
BView::SetViewBitmap(), so no compositor is actually implemented,
app_server drawing capabilities are used.
I made C++ code generator for Wayland interfaces based on existing C code generator to make code more readable and manageable.
Wayland support allows quick and high-quality port of GTK 3+ based applications and other Wayland applications. Xlibe is also an option but, X11 protocol is more complex and harder to implement properly. It also have a lot of cryptic behavior because of its age and uncoodinated extending. Wayland is easier to implement. Current Xlibe implementation have various drawing glitches like black flickering. X11 have multiple input protocols, multiple window manager protocols that are hard to fully implement. X11 is generally considered outdated in Linux ecosystem and it is planned to be retired in flavor of Wayland. GTK developers suggest dropping X11 backend in GTK 5 because of lack of backend developers: Consider dropping the X11 backend (#5004) · Issues · GNOME / gtk · GitLab.