Desktop Summit

Ein "KDE 5" wird es nicht geben, auch kein "KDE SC 5". "Wir haben aus KDE 4 gelernt", sagte Entwickler Aaron Seigo bei dem vielbeachteten Roadmap-Talk auf dem Desktop Summit. Jetzt haben sich die Developer mit den KDE Frameworks 5 einiges vorgenommen.

Die immer komplexer werdende Bibliotheken-Landschaft soll modularisiert und offener werden, damit sich auch fremde Projekte leichter integrieren lassen. Dazu haben die Entwickler eine (einigermaßen komplexe) Matrix aufgestellt, in der sich die existierenden Bibliotheken verorten lassen, Damit möchten sie zeigen, was sich sinnvollerweise einfach in Qt auslagern lässt, beispielsweise wird Kdevelop durch Qdevelop ersetzt. Sowohl Runtime-Tools als auch Bibliotheken lassen sich mit der Matrix kategorisieren, zum Beispiel nach den Kriterien Solution, Qt-Addon (OS-Integration) und Qt-Addon (Funktionalität).

Mit dieser Aufteilung erhoffen sich die Developer eine saubere Trennung von Applikationen und Libraries, sodass Anwender von Änderungen an der darunterliegenden Struktur nichts oder nur wenig mitbekommen - anders als beim leidvollen Umstieg auf KDE 4. Gleich wichtig ist dabei aber die Öffnung für viele Projekte, die mit Qt arbeiten, wie zum Beispiel Qjson. Mehr Details zu der geplanten Matrix und dem Weg dorthin finden sich derzeit nur in den Blogs der Entwickler, zum Beispiel bei Stephen Kelly oder in den beiden Diagrammen aus dem Entwickler-Vortrag: hier und hier (PDFs).

Im Gespräch mit dem Linux-Magazin nennt Kelly vier Hauptgründe für die Umstellung: "Wir wollen Abhängigkeiten reduzieren, Bestandteile zu den neuen Qt-Versionen portieren, die es bei KDE 4.0 schlicht noch nicht gab, 3rd-Party-Entwicklern die Integration in die KDE-Plattform (zukünftig die KDE-Frameworks) erleichtern und die KDE-Plattform in ein Rahmenwerk überführen, wo jede Funktion klar zugeordnet ist. Bei einem Treffen in der Schweiz, im Juni 2011 hat das alles angefangen, auf dem Desktop Summit 2011 haben wir das dann offiziell beschlossen."