Ein Designsystem aus einer Quelle: Wie „Nitida“ GNOME Shell und GTK 4 in CardinalOS vereint

Stand November 2026 · Redaktion CODLAB

Kurzantwort: Auf klassischen Linux-Desktops pflegen Systemleiste (GNOME Shell) und Anwendungsfenster (GTK 4 / libadwaita) ihre Stilregeln getrennt. Für das in Entwicklung befindliche CardinalOS bündelt die Gestaltungsschicht „Nitida“ Farben, Abstände, Radien und Typografie in einer JSON-Token-Quelle, übersetzt die Zielformate deterministisch im Design-Repository und wird schrittweise als Vorschau integriert.

1. Das eigentliche Problem: Nicht fehlende Schönheit, sondern doppelte Wahrheit

Ein anschauliches Beispiel aus dem Desktop-Alltag macht das Problem greifbar: Auf zusammengesetzten Oberflächen verwendet die obere Systemleiste mitunter ein anderes Dunkelgrau als das Einstellungsfenster, das Schnelleinstellungs-Menü nutzt andere Eckradien und Innenabstände als der Dateimanager, und beim Umschalten zwischen hellem und dunklem Modus folgt nicht jede Leiste denselben Abstufungen.

Die Ursache ist technisch nachvollziehbar: GNOME Shell zeichnet die Arbeitsflächen-Umgebung mit einer eigenen CSS-Engine (St / Clutter), während moderne Desktop-Anwendungen auf GTK 4 und die Bibliothek libadwaita setzen. Beide Welten sind für sich genommen sauber konstruiert, lesen ihre Gestaltungswerte jedoch aus unterschiedlichen Quellen und benannten Variablen. Sobald ein Team Farben, Fokusrahmen oder Typografie für ein eigenes Betriebssystem abstimmen möchte, entstehen zwei getrennte Pflegepfade — und bei Änderungen können sie auseinanderdriften.

Parallel zur Vorarbeit für CardinalOS haben wir die Trennung zwischen deklarativer Token-Quelle und generierten Ziel-Stylesheets in unserer öffentlich einsehbaren Studie CodLab Thema dokumentiert (aufgeführt unter Projekte & Produkte). In einer eigenständigen Ausbaustufe führt heute das interne Design-Repository „Nitida“ diesen Ansatz für CardinalOS weiter.

2. Eine einzige JSON-Quelle statt handgepflegter Einzeldateien

Im Design-Repository von „Nitida“ liegen alle Gestaltungswerte in einer einzigen deklarativen Datei (nitida.json) statt verstreut in einzelnen Stylesheets. Sie trennt klar zwischen Entwurfsentscheidungen und abgeleiteten Token-Sätzen:

• Entscheidungen, Maßsystem und Grundflächen (decisioni): Kontrastregeln, eine feste 4-Pixel-Raster-Skala (spazi mit den Stufen 4, 8, 12, 16, 20, 24, 32, 40, 48 Pixel), Eckradien, Typografie sowie die fünf neutralen Hintergrundebenen tela, laterale, superficie, rialzo und incavo für Hell und Dunkel.
• Abgeleitete Farb- und Zustandsrollen (colori und contrasto_elevato): Abgestufte Text- und Rahmenwerte (testo, testo2, testo3, bordo) sowie neun kalibrierte Akzentfamilien (Standard red «Cardinale») mit Rollen wie pieno, su, testo, tenue, selezione und anello — jeweils für die helle, die dunkle und die kontrastreiche Variante.

Das deterministische Skript genera.py übersetzt nitida.json ohne eigene Zahlenwerte in die Zielartefakte des Design-Baukastens:

1. Für GNOME Shell erzeugt genera.py die St-Stylesheets unter shell/ (inklusive getrennter Dateien für Textskalierung sowie movimento.css und movimento-ridotto.css) und die kompakte Zuordnung veste.json.
2. Für GTK 4 / libadwaita und Begleitoberflächen erzeugt derselbe Lauf die Ausgaben unter gtk/, gecko/ (für Cardinal Mail) sowie Browser-Themen unter firefox/ und chrome/.

Für alle erzeugten Artefakte dieses Baukastens stammt damit jeder Farb-, Abstands- und Fokuswert aus derselben Quelle; die schrittweise Einbindung dieser Artefakte in sämtliche Zieloberflächen des künftigen Systems ist noch in Arbeit.

3. Getrennte Prüf-Richter für Kontrast und CSS-Kaskade

Ein ruhiges Erscheinungsbild darf nicht auf Kosten der Lesbarkeit erkauft werden. Gerade gedämpfte Oberflächen neigen dazu, sekundäre Hinweise in kontrastarmen Grautönen anzulegen, die auf einem unkalibrierten Büromonitor bei Tageslicht schwer lesbar sind.

In der Pipeline von „Nitida“ sind Erzeugung und Prüfung bewusst getrennt: Während genera.py ausschließlich Artefakte schreibt, prüfen eigenständige Prüfskripte unter giudici/ (insbesondere armonia.py und cascata.py) die Werte in nitida.json und die erzeugten Stylesheets gegen die WCAG-Kontrastformel (analog zu unserer Web-Prüfung in Barrierefreiheit vor dem Deploy prüfen):

• Primär- und Sekundärtext auf allen fünf Grundflächen: Mindestens 7,0 : 1 im Standardmodus (10,0 : 1 für Sekundärtext im Modus mit erhöhtem Kontrast).
• Tertiärtext, Akzenttext und Statusfarben: Mindestens 4,5 : 1 gegenüber den zugehörigen Flächen (7,0 : 1 bei erhöhtem Kontrast), damit gedämpfte Hinweise lesbar bleiben.
• Fokusring (anello) und Kontrollränder (bordo): Mindestens 3,0 : 1 auf den definierten Oberflächen gemäß WCAG 1.4.11; die Prüfung gilt für die Token-Paare des Baukastens, während die vollständige Prüfung jedes einzelnen Steuerelements in allen künftigen Apps noch vor dem Release liegt.

Unterschreitet ein geänderter Tokenwert in nitida.json eine dieser Schwellen oder überschneiden sich Selektoren in der Shell-Kaskade, melden die Prüfskripte unter giudici/ einen Fehler.

4. Bewegung mit Maß: Bewegungs-Stylesheets und Entwurfsregel für reduzierte Animation

Animationen helfen auf einem Desktop nur dann, wenn sie räumliche Orientierung geben — etwa beim Wechsel auf eine benachbarte Arbeitsfläche. Werden Übergänge zu langsam, zu federnd oder allgegenwärtig, ermüden sie die Augen und stören Menschen mit vestibulärer Empfindlichkeit.

Im Design-Repository von „Nitida“ ist diese Vorgabe zunächst in den erzeugten Artefakten verankert: genera.py gibt neben shell/movimento.css mit kurzen Übergangsdauern aus nitida.json ein eigenes Stylesheet shell/movimento-ridotto.css aus, das diese Shell-Übergänge auf 0 ms setzt, und legt die zugehörigen Bewegungswerte in veste.json ab. Als Entwurfsregel für CardinalOS sollen künftig sowohl die Shell über enable-animations = false in GSettings als auch eingebettete Web- und Hilfsoberflächen über prefers-reduced-motion: reduce dekorative Bewegungen abschalten; da derzeit nur eine unsignierte Teilvorschau vorbereitet ist, steht die durchgängige Prüfung auf allen lebenden Desktop-Oberflächen noch vor dem Release aus — während unser Maskottchen Mochi hier auf codlab.de diese Regel bereits einhält.

5. Zehn geplante Anwendungen der Cardinal-Familie unter einem Dach

Ein Designsystem beweist seinen Wert erst im späteren Zusammenspiel mehrerer Programme. Für CardinalOS sind zehn aufeinander abgestimmte Anwendungen in der Cardinal-Familie geplant: Cardinal Write, Cardinal Sheets, Cardinal Slides, Cardinal PDF, Cardinal Mail, Cardinal Chat, Cardinal Photo, Cardinal Film, Cardinal Studio und Cardinal Host.

Statt zehn riesige Codebasen im Alleingang neu zu schreiben, baut CodLab auf bewährter freier Software auf, hält die Upstream-Urheberhinweise sichtbar und richtet Kopfleisten, Seitenleisten, Dialoge und Symbolsprache schrittweise an den „Nitida“-Tokens aus. Aktuell ist Cardinal Photo auf dem Entwicklungsrechner installiert und insgesamt sechs Kandidaten sind in der Entwicklungsumgebung vorbereitet, während weitere Programme — darunter Cardinal Slides und Cardinal Studio — noch Integrations-, Signatur- und Lizenzprüfungen durchlaufen. Ein Programmname auf der Website bedeutet daher ein geplantes Arbeitsziel, noch kein veröffentlichtes Paket.

6. Ehrliche Systemgrenzen: Was „Nitida“ heute leistet — und was noch aussteht

Zu seriöser Systementwicklung gehört, den tatsächlichen Arbeitsstand und technische Grenzen offen beim Namen zu nennen:

• Aktueller Entwicklungsstand (November 2026): Weder CardinalOS noch „Nitida“ sind als öffentliches Systemabbild ausgeliefert. Der JSON-Generator und die Kontrastprüfer laufen deterministisch im Design-Repository; auf dem Desktop existiert derzeit lediglich eine unsignierte Teilvorschau für Leisten- und Glasflächen, während Dock, Aktivitäten-Übersicht, Fensterrahmen, Sperrbildschirm, globales GTK und die Familien-Apps noch zur vollständigen Integration anstehen.
• Drittanbieter-Toolkits: Auf einem offenen Betriebssystem darf jeder Nutzer beliebige Programme aus Flathub oder Containern installieren. Anwendungen, die ihre gesamte Oberfläche mit einem eigenen Grafik-Toolkit zeichnen — etwa manche Electron-Programme, Spiele-Launcher oder spezialisierte CAD-Werkzeuge — lesen keine System-Tokens von GTK 4 aus. Sie behalten ihr gewohntes eigenes Aussehen und werden nicht erzwungen umgefärbt.
• Respekt vor App-Markenfarben: Wo Drittanwendungen gezielt eigene Akzentfarben für Marken- oder Warnzustände definieren, soll „Nitida“ diese nicht blind überschreiben, um Bedienfehler durch verfälschte Signalfarben zu vermeiden.

Wer den Fortgang bis zur ersten öffentlichen Ausgabe verfolgen möchte, findet auf der Produktseite zu CardinalOS auf codlab.de Aufnahmen aus isolierten GNOME-Entwicklungssitzungen sowie auf cardinalos.org die unverbindliche Vormerkung zur Verfügbarkeit.