Wer seinen Linux-Desktop gerne individuell gestaltet, stößt bei aktuellen GNOME-Versionen schnell an seine Grenzen. Während andere Desktops umfangreiche Personalisierung erlauben, bringt GNOME mit jedem Release neue Hürden mit. Das Ändern von Themes, vormals mit ein paar Klicks erledigt – erfordert heute technische Umwege, Geduld und einiges an Hintergrundwissen.
Aber warum ist das eigentlich so?
Und weshalb reagieren GNOME-Entwickler so restriktiv auf den Wunsch nach mehr Gestaltungsfreiheit? Dieser Beitrag befasst sich mit den wichtigsten technischen und konzeptionellen Hindernissen und erklärt, was sich hinter den Kulissen verändert hat.
I. Teils heftige Kritik an Entscheidungen der GNOME-Entwickler
Das restriktive Theming mit Libadwaita und GTK4
Mit der Einführung von Libadwaita für neue GNOME-Apps wurde das Theming auf ein Minimum zurückgefahren. Individuelle Themes lassen sich praktisch nicht mehr auf GTK4/Libadwaita-Anwendungen anwenden.
Das führt zu einem kontrollierten, aber auch unflexiblen Erscheinungsbild und verhindert, dass das Aussehen System-weit frei gewählt werden kann.
Entfernung klassischer Desktop-Konzepte
GNOME hat sich von vielen traditionellen Elementen verabschiedet, etwa der klassischen Fensterleiste (mit Minimieren-/Maximieren-Schaltflächen) oder dem anpassbaren Panel. Viele User empfinden diese Designentscheidungen als unnötige Einschränkung und vermissen konfigurierbare Elemente oder klassische Menüleisten.
Abbau rückwärtskompatibler Funktionen
Ältere Apps, die kein Libadwaita/GTK4 nutzen, werden nach und nach aufgegeben, was beispielsweise Forks wie den Linux-Mint-Apps (X-Apps) vor immer größere Schwierigkeiten stellt, da sie neue Funktionen oder Bugfixes nicht einfach übernehmen können, sobald GNOME-Apps umgebaut wurden.
Geringe Rücksicht auf Drittdesktop-Projekte
Andere Desktopumgebungen wie Cinnamon, Xfce oder Mate, die teilweise auf GTK (und früher GNOME-Technologien) basieren, werden durch die GNOME-Entscheidungen immer häufiger ins Abseits gedrängt, weil viele Neuerungen und Frameworks nicht mehr Plattform-übergreifend, sondern nur noch GNOME-eigen umgesetzt werden.
II. Hindernisse für Theme-Anpassungen im aktuellen GNOME
Einführung von GTK4 und Libadwaita
Moderne GNOME-Apps auf Basis von GTK4 mit Libadwaita ignorieren externe Themes vollständig.
Die App-Entwicklung legt das Farbschema, die Komponenten und Animationen fest, und die Benutzer können das Aussehen fast gar nicht mehr beeinflussen. Nur sehr eingeschränkte Anpassungen, etwa mit Tools wie “Gradience”, sind überhaupt noch möglich – und das auch
nur bezüglich Farbnuancen, nicht für das ganze Theme.
Trennung von Shell-Theme und Applikations-Theme
Das GNOME-Shell-Design (z. B. Oberflächen-Elemente, Panel, Aktivitätenübersicht) kann man durch „User Themes“ Extension zwar anpassen, aber diese Änderungen wirken sich nicht auf die meisten
Anwendungen aus. Besonders GTK4/Libadwaita-Apps bleiben davon völlig unberührt.
Reduzierte Einstellungen für Benutzer
Die früher in den Systemtools vorhandene Möglichkeit, Themes auszuwählen und sogar zu
kombinieren, wurde durch deutlich minimalistischere Optionen ersetzt. Es ist meist nur noch ein Wechsel zwischen den (vorgegebenen) hellen und dunklen Designs möglich; individuelle Stylesheets, Fensterdekorationen oder Icons müssen manuell hacky gesetzt werden.
Fehlende Plattform-übergreifende Toolkits
Sobald Programme – etwa auf Qt oder älteren GTK-Versionen – laufen, entsteht Inkonsistenz. GNOME steuert den Look neuer Apps so rigide, dass gemischte Toolkits deutlich unterschiedlich aussehen, was die Theme-Anpassung umso schwieriger macht.
III. Versuche, die Libadwaita-Beschränkungen teiweise zu umgehen
Die Libadwaita-Beschränkungen bei Theme-Anpassungen im aktuellen GNOME lassen sich nur teilweise und mit Einschränkungen umgehen.
– Über eigene CSS-Dateien in ~/.config/gtk-4.0/gtk.css kann man Farben und einzelne Elemente („tinting“) beeinflussen, z.B. mithilfe des Tools Gradience oder farbspezifischer Hacks.
Das betrifft vor allem Farbvarianten, nicht komplette Themes.
– Für unterschiedliche Licht-/Dunkel-Varianten kann man mit Shell-Skripten und Extensions wie Night-Theme-Switcher automatisiert die jeweils passende CSS-Datei hin- und herkopieren. Apps müssen danach jedoch neu gestartet werden, damit die Anpassungen greifen.
– Flatpak-Anwendungen benötigen spezielle Berechtigungen, damit die lokalen CSS-Anpassungen überhaupt wirken (flatpak override –filesystem=xdg-config/gtk-4.0:ro).
– Diese Methoden sind Zwischenlösungen („Hacks“) und bieten keinen vollwertigen Theme-Support, da große Teile der UI weiterhin der Vorgabe von Libadwaita folgen und manche Anpassungen schlichtweg ignoriert werden. Änderungen am Widget-Stil oder Funktionsweise sind nicht möglich.
Es gibt technische Workarounds für Farbanpassungen und einzelne Tweaks – ein vollständiges Theme lässt sich in modernen GNOME/Libadwaita-Apps kaum mehr realisieren. Ein echter Theme-Wechsel ist bei modernen GNOME/Libadwaita-Apps nicht mehr möglich – die Hacks liefern nur oberflächliche, instabile Lösungen.
Die GNOME-Entwicklung verfolgt bewusst diese Policy.
IV. Die Zielgruppe von GNOME
GNOME richtet sich an Anwender, die einen effizienten, auf das Wesentliche konzentrierten Workflow bevorzugen, mit minimalistischem Design. Es soll „einfach funktionieren“ und eine intuitive, klare Oberfläche bieten, die ohne unnötige Ablenkungen auskommt.
Kurzum – eine puristische Arbeitsumgebung für Leute, die eine aufgeräumte und zugängliche Desktop-Erfahrung ohne viel Schnickschnack wünschen.
Aufgrund der vorgenannten Einschränkungen ist die aktuelle GNOME-Version für mich jedoch keine Option mehr.
6
Eine Reaktion
Hallo,
meine vollste Zustimmung.
Für Arch gibt es im AUR ein Paket namens libadwaita-without-adwaita (https://aur.archlinux.org/packages/libadwaita-without-adwaita): eine feine Sache.
Ich habe bei meinem EndeavourOS in der Datei /etc/environment „export GTK_THEME=Arc-Darker“ eingefügt und schon habe ich mit Kvantum für QT- und KDE-Apps in meinem bevorzugten XFCE ein schönes homogenes Design. Das funktioniert auch ohne dem o.a. libadwaita-without-adwaita.