Das GNOME-Projekt hat die Version 1.5 der Libadwaita-Bibliothek veröffentlicht, die eine Sammlung von Komponenten für das Styling der Benutzeroberfläche gemäß den Empfehlungen der GNOME HIG (Human Interface Guidelines) umfasst. Die Bibliothek enthält fertige Widgets und Objekte zur Entwicklung von Anwendungen, die dem allgemeinen GNOME-Stil entsprechen und deren Oberfläche sich flexibel an Bildschirme jeder Größe anpassen kann. Der Code der Bibliothek ist in C geschrieben und unter der LGPL 2.1+ Lizenz verfügbar.
Die libadwaita-Bibliothek wird zusammen mit GTK4 verwendet und beinhaltet Komponenten des GNOME-Themes Adwaita, die aus GTK in eine separate Bibliothek ausgelagert wurden. Die Auslagerung visueller Elemente von GNOME in eine separate Bibliothek ermöglicht es, notwendige Änderungen für GNOME unabhängig von GTK zu entwickeln. Dies gibt den GTK-Entwicklern die Möglichkeit, sich auf die Grundfunktionen zu konzentrieren, während die GNOME-Entwickler erforderliche Anpassungen der Gestaltung schneller und flexibler vorantreiben können, ohne die GTK-Bibliothek selbst zu betreffen.
Die Bibliothek enthält standardisierte Widgets, die verschiedene Elemente der Benutzeroberfläche abdecken, wie Listen, Panels, Bearbeitungsblöcke, Buttons, Tabs, Suchformulare, Dialogfenster usw. Die angebotenen Widgets ermöglichen die Erstellung universeller Oberflächen, die sowohl auf großen Bildschirmen von PCs und Laptops als auch auf kleinen Touchscreens von Smartphones gleichmäßig funktionieren. Die Benutzeroberfläche der Anwendungen passt sich dynamisch an die Bildschirmgröße und die verfügbaren Eingabegeräte an. Die Bibliothek umfasst außerdem ein Set von Adwaita-Stilen, die das Aussehen gemäß den Empfehlungen von GNOME anpassen, ohne dass eine manuelle Anpassung erforderlich ist.
Die wichtigste Neuerung in libadwaita 1.5 ist die Neugestaltung der adaptiven Widgets zur Erstellung von Dialogfenstern, die sich an die sichtbare Fläche anpassen. Im Gegensatz zu traditionellen Dialogen, die in separaten Fenstern angezeigt werden, werden die neuen Dialoge auf der Client-Seite generiert, innerhalb bestehender Fenster gerendert und dürfen nicht über das übergeordnete Fenster hinausgehen. Dieser Ansatz vereinfacht die Erstellung universeller Dialoge, die mit Benutzeroberflächen für mobile und Desktop-Systeme kombiniert werden können, und bietet zusätzliche Möglichkeiten zur Verwaltung der Dialoge (zum Beispiel ist es nicht erforderlich, das Übertreten der Fenstergrenzen zu überwachen, es kann das Verhalten der Schaltflächen zum Schließen ausgewählt werden, die automatische Vollbilddarstellung in mobilen Versionen der Anwendungen wird sichergestellt, der Stil des aktuellen Fensters wird bei der Verdunkelung des Dialogs berücksichtigt, nicht der des Systems).
In Zukunft planen wir die Implementierung einer weiteren Variante solcher Dialoge, die nicht an Fenster, sondern an Tabs innerhalb eines Fensters gebunden sind. Dies könnte in Anwendungen wie Browsern gefragt sein, damit dialogbezogene Tabs das Hauptfenster beim Wechseln zwischen Tabs nicht überdecken.
Für mobile Geräte wurde die Unterstützung für die Platzierung von Dialogen in Form von Bottom Sheets umgesetzt, die am unteren Rand des Bildschirms verankert sind, anstatt zentriert. So behalten angeheftete Dialoge den Überblick und verhindern Verwirrung beim Schließen von Fenstern – in solchen Dialogen bleibt ein Teil des übergeordneten Fensters sichtbar, und die Schaltflächen zum Schließen des übergeordneten Fensters sowie des Dialogs sind klar voneinander getrennt, sodass sie nun schwer zu verwechseln sind.
Die Verwaltung neuer Dialoge erfolgt über die Klasse AdwDialog, deren Nutzung in den meisten Fällen der Verwendung der Klasse GtkWindow ähnelt. Die Unterschiede beziehen sich hauptsächlich auf die Anzeige- und Schließvorgänge. So wurde beispielsweise die Eigenschaft „:transient-for“ durch einen Parameter in der Funktion adw_dialog_present() ersetzt, ein neues Signal „::close-attempt“ hinzugefügt und die Verarbeitung des Parameters „:can-close“ geändert. Statt der Klassen AdwPreferencesWindow, AdwAboutWindow und AdwMessageDialog sollen die Klassen AdwPreferencesDialog, AdwAboutDialog und AdwAlertDialog verwendet werden.
Dialoge ohne ein übergeordnetes Fenster werden nach wie vor als separate Fenster behandelt. Ebenso werden Dialoge, deren übergeordnete Fenster nicht für die Platzierung von Dialogen geeignet sind, wie beispielsweise solche, die keine Größenänderung zulassen, oder für die die Klassen AdwWindow und AdwApplicationWindow nicht vorhanden sind, ebenfalls als eigenständige Fenster fungieren.
Änderungen in Libadwaita 1.5, die nicht mit der Überarbeitung von Dialogen zusammenhängen:
- Der Klasse AdwEntryRow wurde die Eigenschaft „:text-length“ hinzugefügt, um die Größe des eingabefeldes zu begrenzen.
- Der Klasse AdwMessageDialog wurde die Methode remove_response() hinzugefügt.
- In der Klasse AdwBreakpointBin, die eine beliebige Anpassung der Benutzeroberfläche in Abhängigkeit von der Fenstergröße ermöglicht, wurde die Möglichkeit zur programmatischen Entfernung von Haltepunkten hinzugefügt.
- In der Klasse AdwSwipeTracker wurde das Flag „:allow-window-handle“ hinzugefügt, das das Scrollen über die obere Leiste ermöglicht (verwendet in Listen, die am unteren Rand angeheftet sind).
- Die Helligkeit der Farben, die beim Verdunkeln von Fenstern im Dunkelmodus verwendet werden, wurde erhöht.
Quelle: opennet.ru
