Compositing nach X11
KDE Plasma auf dem Weg nach Wayland
X-Server bleibt erhalten
Auf den Plattformen Desktop und Netbook kann von einem reinen Wayland-System daher auf absehbare Zeit keine Rede sein. Es gibt zu viele Anwendungen, die auf Legacy-Unterstützung angewiesen sind und bei denen auch keine Portierung auf Wayland zu erwarten ist.
Gerade auch die Tatsache, dass Wayland nicht auf allen Plattformen funktioniert (siehe NVIDIA Treiber) macht deutlich, dass für die großen Desktopumgebungen wie die KDE Plasma Workspaces vorerst X11 die erste Wahl bleiben muss. Eine zu frühe Umstellung auf Wayland würde Regressionen mit sich bringen und für die KDE Plasma Entwickler ist es das höchste Gebot, den Desktop nicht zu zerstören.
Auch nach einer erfolgten Umstellung auf Wayland muss die X11-Unterstützung erhalten bleiben. Auch wenn die meisten Anwender Wayland verwenden können, wird es auf lange Zeit noch Anwendungsfälle geben, die einen X-Server erfordern. Die Desktopumgebungen müssen daher in ihrer Entwicklung die Kompatibilität mit X berücksichtigen. Wird die Abwärtskompatibilität nicht berücksichtigt, so könnte im schlimmsten Fall Wayland von den Nutzern abgelehnt werden und sie bleiben bei X11.
Umstellung auf Wayland
Für die KDE-Plasma-Entwickler gibt es mehrere Möglichkeiten, wie man Wayland angehen könnte. Diese sind:
- das Ignorieren von Wayland
- das Ignorieren von X11
- einen neuen, auf Wayland basierten Compositor und eine Desktop Shell parallel entwickeln
- die schrittweise Migration auf Wayland
Offensichtlich sind die ersten zwei Optionen nicht praktikabel. Wie in der Einleitung gezeigt, bietet Wayland eine verbesserte Architektur, von der die KDE Plasma Workspaces auch profitieren sollen. Die zweite Option ist nicht möglich, da wie im letzten Abschnitt gezeigt, der X-Server uns auf absehbare Zeit erhalten bleibt. Eine Einstellung der Entwicklung für X11 würde zu großen Akzeptanzproblemen unter den Nutzern führen.
Auch die dritte Option ist nur schwer umzusetzen. Natürlich mag es verlockend klingen, eine alte Codebasis, zugeschnitten für ein nun obsoletes Fenstersystem, zu verwerfen. Jedoch stecken in KWin mehr als 12 Jahre Entwicklung und Fenstermanagement-Expertise. Durch Wayland ändert sich das grundlegende Verhalten jedoch nicht: ein Fenster ist immer noch ein Fenster. Zieht man noch die verfügbaren Entwicklerresourcen hinzu, wird offensichtlich, dass es nicht möglich ist, gleichzeitig an den X11-Workspaces zu entwickeln und nebenher noch einen neuen Wayland Workspace zu entwickeln.
Die zweite und dritte Option kommen auch mit dem großen Problem, dass es einen Tag X gibt, an dem die allgemeine Umstellung von X11 auf Wayland erfolgen würde. Dies hätte vermutlich ähnliche Auswirkungen wie die Umstellung von KDE 3.5 auf KDE Plasma Workspaces. Vieles wäre unfertig und schlecht getestet, die Akzeptanz der Nutzer vermutlich eher schlecht. Nutzer würden lieber auf X11 bleiben, womit nichts gewonnen wäre.
