Ich habe Libadwaita hier bereits mehrfach im Zusammenhang mit der GNOME-Entwicklung erwähnt. Es handelt sich dabei um den GTK 4-Nachfolger von Libhandy, das unter GTK 3 zur Umsetzung der Designkonzepte der GNOME Human Interface Guidelines (HIG) zuständig war. Der technische Hintergrund dazu kann in einem Artikel von GNOME-Entwickler Adrien Plazas nachgelesen werden.
Human Interface Guidelines umsetzen
Eines der zentralen Ziele der Bibliothek Libadwaita als Ergänzung zum GTK-Toolkit ist es, die Erstellung von Anwendungen zu erleichtern, indem die Komponenten und Designpraktiken verwendet werden, die den GNOME-Anwendungsdesign-Ansatz gemäß den neuen Human Interface Guidelines (HIG) ausmachen.
Die Entwickler hatten versprochen, eine stabile Version von Libadwaita noch vor Jahresende vorzulegen und das haben sie auch geschafft. Gestern erschien Libadwaita 1.0. Es setzt die meisten der Funktionen von Libhandy für GTK 4 um, bringt aber auch einige Verbesserungen wie etwa neue Widgets mit. So bietet Libadwaita 1.0 als vielleicht wichtigste Änderung ein völlig überarbeitetes Stylesheet für den Adwaita-Style, das nicht mehr wie in den letzten Jahren ein Teil von GTK, sondern in der Bibliothek selbst verankert ist. Das erleichtert eine unabhängige Entwicklung mit von GTK unabhängigen Updates.
Der neue, komplett neu gestaltete Libadwaita-Style ist moderner, bietet neue Stil-Klassen, unterstützt die Neueinfärbung zur Laufzeit und bietet unter anderem eine API zur Unterstützung des systemweiten Dark Modes sowie verbesserte Benachrichtigungen und vieles mehr. Weitere Details hierzu enthält ein Blogeintrag von Allan Day. Dabei ist der neue Stil der Kopfleisten mit den besser sichtbaren Icons nicht kompatibel mit dem GTK Standard-Stil.
Kritik am zu starren Konzept
Libadwaita 1.0 ist ein wichtiger Meilenstein bei der Entwicklung von GNOME 42. Aber nicht überall herrscht Freude über die Entwicklung. Die Entwickler von Pop!_OS sehen sich durch die für sie wahrgenommenen Einschränkungen beim Theming dazu veranlasst, eine eigene Desktop-Umgebung zu erstellen. App-Entwickler haben einen offenen Brief an die GNOME-Entwickler veröffentlicht, indem sie sich beschweren, dass ihre Apps in ein einziges, zu starres Stylesheet gezwungen werden.
Die traurige Landschaft der UI-Libs in Linux…
Schon diese Vielfalt an sich ist ja hauptsächlich ärgerlich. Aus halbwegs offensichtlichen Gründen (Einheitlichkeit etwa).
Und dann: Eine Lib kämpft mit/gegen ihren FOSS-Ursprung, und man muss jeden Tag damit rechnen, dass es neue Lizenzprobleme gibt. Kann man guten Gewissens eigentlich nicht mehr nehmen. Wenn man denn die Wahl hätte (Vielfalt, yeah)…
Die andere Lib ist technisch noch weiter abgehängt von modernen kommerziellen Frameworks (WPF, Apple; oder auch Avalonia natürlich). Und die Entwickler sind komisch. Irgendwie hat man immer das Gefühl, sie kämpfen da gegen irgendwas. Gegen das Plasma-Team, gegen Leute die anderes Styling wollen, usw… Dann so komische Dinge wie CSD. So schön die Idee wäre: Aber doch nicht so als Insellösung… Dann muss es schon irgendwie ein bisschen ausgearbeitet sein, damit das nicht alles komplett wie selbstgebastelt aussieht. Aber das ist den GTK-Leuten alles komplett egal; die denken in ihrem Elfenbeinturm (den es eigentlich garnicht geben dürfte, denn sie erwähnen immer, dass sie kein zentral koordiniertes Team sein, sondern nur ein wilder Haufen Bastler; was zumindest einiges erklären würde wenn man sich auf diese Nebelkerze mal einlässt).
Und dann gibt es noch x kleine Libs, die aber im großen Zusammenhang wohl nicht weiter nennenswert sind (zum Glück; muss man sagen).
Das war früher mal gefühlt so, dass Linux da ein bisschen weiter ist als Linux. Vielleicht war es auch immer nur etwas, was ich mir eingeredet habe. Heute ist es definitiv weit weg davon; wie
Wer sich bei der GUI seines Programms nicht von den (willkürlichen) Beschränkungen der GNOME/GTK-Entwickler abhängig machen will, sollte sich Flutter anschauen.
Files first port to Adwaita/GTK4 | GNOME 42
https://www.youtube.com/watch?v=rGqlz0slL5o
Frohes neues Jahr allerseits!
Dem letzten Absatz würde ich so nicht zustimmen.
System76 kämpft vermutlich eher damit, dass sie die Shell durch Extensions relativ stark verändern und nicht so sehr mit den GTK-Themes.
Und in dem verlinkten offenen Brief geht es darum, dass Distributionen kein verändertes GTK-Theme usw. ausliefern sollen und nicht um libadwaita.
Kritik kam da eher von Distributionen, die anstatt einem veränderten Theme nun wohl eine modifizierte Version von libadwaita ausliefern müssen. Und das betrifft dann wohl auch DEs wie KDE, wenn sie z.B. den Look von GTK Anwendungen an den von Qt Anwendungen anpassen wollen.
Was System76 angeht, so sagte der Entwickler auf Reddit: »…There are things we’d like to do that we can’t simply achieve through extensions in GNOME. Extensions in general feel like a hack. And what we want to do with our desktop differs from GNOME, so it’s not like the option to merge pop-shell and COSMIC into GNOME Shell would be a welcome thing.« Den offenen Brief muss ich wohl nochmals lesen.
Ja eben, Extensions für die Shell.
Aber er sagt doch, er will keine Extensions, da sie erstens nicht tun, was er braucht und er sie zudem als Hack empfindet. Er will also nach meinem Verständnis sein System direkt über GTK/die HIG so gestalten wie er möchte. Und das wird mit libadwaita ja eher schwerer.
Extensionsfür die Shell sollten mit Libadwaita afaik doch aber praktisch nichts zu tun haben?
Ich bin nicht der Kenner von GNOME- und GTK-Interna. Ich vermute, daraus resultiert hier ein Missverständnis.