Martin.tex

\chapterwithauthor{Martin Gr\"{a}\ss{}lin}{Evolution of Windowing Systems}
\authorbio{Martin Gr\"{a}\ss{}lin is a KDE developer since 2008 with the primary focus on KWin, the window manager and compositor of the KDE Plasma workspaces. He is employed by BlueSystems GmbH to work on KWin and Plasma.}

\noindent{}When Matthias Ettrich announced the Kool Desktop Environment it was intended for Linux/Unix and by that also for the X11 Windowing System. At that time it was the only available windowing system for Unix-like systems. Matthias didn't want to write a dedicated window manager for this system. He thought that "at the beginning, the KDE panel will work as an Fvwm-Module".

Nowadays KWin, the window manager started by Matthias for KDE 2 in 1999, is one of the oldest components in the KDE Plasma workspaces and the largest single code base of Plasma. It is one of the pillars of Plasma and an extremely important part of the user experience of Plasma. KWin, unlike many other components from KDE 2, survived several technology transitions. The biggest threat to the existence of KWin was the time before KDE 4 was released. A disruption on the desktop happened: Compiz! Finally there was the chance to unify the desktop world and have just
one major window manager.

Compiz was a huge change. It made use of "compositing" directly in the window manager. Compositing is a kind of hack added to the X windowing system to make it possible to have translucent windows. The extensions allow interested applications to get notified when a window changes its content (damage extension) and to redirect the windows from rendering directly to the X-Server to a pixmap (composite extension). A compositor can now take all the windows pixmaps and render them as the final image, making use of translucency, arranging them in different ways and applying smooth transitions. One of the core parts of the XServer got replaced by two extensions and an additional application. It was a sign of defeat in retrospection. The X developers decided to hand over responsibility to other applications because the XServer was not able to deliver the required features.

In the beginning there was only xcompmgr and various forks (including one by KDE) - an additional process adding translucency, drop shadows and simple animations, not integrated in any way with the window manager. Compiz changed that significantly. A window manager built around the idea of compositing, making use of OpenGL for all rendering. It demonstrated functionality which just was not possible on other systems. Of course KDE wanted to integrate that technology and Compiz was a true competitor to KWin. Yours truly, a user back at that time, questioned the sanity of the KDE developers to implement compositing in KWin instead of just using Compiz. The problem for Compiz back then at the end of the first decade of this century was the hard dependency on compositing and on OpenGL. Both are things which could not be guaranteed. Basing your environment on this technology was not an option (yet) and having two window manager with different sets of functionality was not a good idea. So the better option was to extend the excellent window manager KWin with the functionality of a compositor: KWin 4 was born.

But over the years we learned how much compositing was more of a hack than a proper solution. Why is it not possible to have thumbnails for minimized windows? Yes one can hack around this as well, but then legacy applications might think they are not minimized and continue to play the video instead of pausing it and more. Why does it have to stutter when unminimizing a window? Why is it not possible to transform the pointer input events in a way that it matches the transformed window positions? Why do we get invalid screen content when a window first opens (especially when using OpenGL)? Why is it not possible to resize windows in truly smooth ways?

And then there is the problem of security. X11 being designed in the 1980s completely lacks the idea of malicious processes. It is trivial to write a key logger, it is super easy to get to the content of the windows and their positions. This allows all kinds of wonderful attacks. Your malicious application wants to get  the user's password: just replace the lock screen. Your malicious application wants to get the root password: just install a key logger when a window asking for the password is added. You want to take over the browser and send it to fakebank.com instead of bank.com: just send the right key events and put a window on top of the browser to simulate that you are on bank.com.

This all shows that X11 is not suited for today's world - neither for desktop nor for mobile. Something new was needed, something like an X12. Many contenders existed to replace the aging X windowing system, but none gained traction. Except for Wayland. A new windowing system, designed from ground up with the aim of "every frame perfect". Designed by X11 developers applying the lessons learned from X and taking the good things to the new world.

This development again means a disruption for Plasma and especially KWin. A system based around X11, developed for X11. How should that ever go to Wayland. Maybe it is easier to write a new system from scratch? Something which gets rid of the legacy and does it right from the start? But what if Wayland fails just like all the other X-replacement-systems? The community decided to go the long walk: bring the system to the new world without having to rewrite everything. Especially for KWin this meant a huge effort. The code base needed to become windowing system independent, needed to support both X11 and Wayland windows.

Now this effort is slowly reaching an end. This article is written in a Plasma session on Wayland in a KWrite using Wayland instead of X11. But of course it will still be a long way till we finally get rid of X11. There are many X11 specific functionalities which are essential to users' workflows, but which are built around the insecure parts of X11. It will take time to identify the workflows and add sufficient (and secure) replacements.