Neuer Ansatz für das KDE-Styling

Ein Essay von Arjen Hiemstra erläutert bestehende Probleme beim Styling von KDE Plasma und KDE Apps und stellt mit Union eine mögliche Lösung vor.

Das Problem, wie Arjen es beschreibt, sind vier unterschiedliche Ansätze, das Breeze-Design umzusetzen, was nicht nur für die Plasma Next Initiative ein Problem darstellt, sondern selbst kleine Änderungen schwierig macht.

Gewachsene Ansätze

Ursprünglich gab es nur Qt-Widgets und ein System, um diese zu gestalten. Dann kam Plasma mit SVG-basiertem Styling, gefolgt von QtQuick mit einem weiteren Styling-System. In einem Vortrag vom vergangenen Jahr von der KDE-Konferenz Akademy erklärt Arjen das Problem im Detail. Besonders Designer ohne Programmierkenntnisse tun sich schwer mit den verschiedenen Ansätzen.

Das Problem wurde bereits vor Jahren erkannt, ist aber nicht leicht zu lösen. Die zu unterschiedlichen Zeiten entwickelten Ansätze existieren nebeneinander und verwenden Techniken aus der jeweiligen Entstehungszeit. Das Hauptproblem dabei sind die daraus resultierenden vollkommen unterschiedlichen Rendering-Stacks.

Render-Problem

Rendering-Stacks sind die Abfolge von Prozessen, Technologien oder Softwarekomponenten, die zusammenarbeiten, um Inhalte visuell darzustellen. Um das Problem der unterschiedlichen Rendering-Stacks zu lösen, musste eine Kompatibilitätsschicht entwickelt werden, die es erlaubt, den gleichen Render-Code über alle verwendeten Design-Ansätze hinweg verwenden zu können.

Union solls richten

Hier kommt Arjens Projekt Union ins Spiel. Dabei handelt es sich um ein Styling-System, das all die unterschiedlichen Ansätze in einer einzigen einheitlichen Styling-Engine vereinen soll, die alle unterschiedlichen Technologien unterstützt, die zum Stylen von KDE-Anwendungen verwendet werden.

Drei Ebenen

Union besteht aus drei Teilen: einer Eingabeebene, einer Zwischenebene und einer Ausgabeebene. Die Eingabeebene besteht aus Plug-ins, die ein Eingabedateiformat mit einer Stilbeschreibung lesen und interpretieren und es in eine abstraktere Beschreibung dessen umwandeln können, was gerendert werden soll. Wie das geht, wird durch die mittlere Zwischenebene definiert, eine Bibliothek mit der Beschreibung des Datenmodells und einer Methode zum Definieren, auf welche Elemente Dinge angewendet werden sollen. Zu guter Letzt besteht die Ausgabeebene wiederum aus Plug-ins, die die Daten aus der Zwischenebene verwenden und sie in tatsächliche Rendering-Befehle umwandeln, je nach Bedarf für einen bestimmten Rendering-Stack.

Flexibel, aber restriktiv genug

Das klingt nach viel Arbeit und ist es wohl auch. Die Zwischenschicht muss einerseits flexibel genug sein, um verschiedene Anwendungsfälle zu bewältigen, andererseits aber auch starr genug, damit es schwer wird, – ob absichtlich oder unabsichtlich – Abhängigkeiten zwischen der Eingabe- und Ausgabeschicht zu schaffen. Abgesehen davon ist das Ersetzen des gesamten Styling-Stacks eine Menge an Arbeit.

Aufgeteilt

Zunächst wurde das Problem in besser handhabbare Teile zerlegt. Zunächst konzentrierte man sich auf die Zwischenschicht und verwendete dort Plasmas SVG-Themen als Eingabeformat und einen QtQuick-Stil als Ausgabe. Das Ergebnis ist, dass Union zwar noch keinen vollständigen QtQuick-Stil implementiert, aber die meisten grundlegenden Steuerelemente, damit etwas wie Discover ausgeführt werden kann, ohne völlig fremdartig auszusehen, funktionieren.

Die Community ist gefragt

Dennoch bleibt noch viel zu tun. Zunächst einmal wird für ein wirklich einheitliches Styling-System für KDE eine QtWidgets-Implementierung benötigt. Die Arbeit daran hat bereits begonnen, stellt sich aber als schwieriger heraus als die QtQuick-Implementierung. Arjen würde Plasmas SVG-Styling gerne durch CSS als Eingabeformat ersetzen, allerdings scheint es keine gute CSS-Parser-Bibliothek zu geben.

An diesem Punkt ist die Community gefragt, um mehr Input zu erhalten. Der Code zum Testen von Union ist auf invent.kde.org/plasma/union zu finden, für Diskussionen wurde ein Matrix-Kanal eingerichtet.