Le projet GNOME a publié la version de la bibliothèque Libadwaita 1.5, qui inclut un ensemble de composants pour le style de l'interface utilisateur, conforme aux recommandations GNOME HIG (Human Interface Guidelines). La bibliothèque comprend des widgets et des objets prêts à l'emploi pour construire des applications en accord avec le style général de GNOME, dont l'interface peut s'adapter de manière réactive à des écrans de toutes tailles. Le code de la bibliothèque est écrit en C et est distribué sous la licence LGPL 2.1+.
La bibliothèque libadwaita est utilisée conjointement avec GTK4 et inclut des composants du thème Adwaita couramment utilisé dans GNOME, qui ont été extraits de GTK pour devenir une bibliothèque distincte. La séparation des éléments de design visuel de GNOME dans une bibliothèque distincte permet de développer les modifications nécessaires pour GNOME indépendamment de GTK, ce qui permet aux développeurs GTK de se concentrer sur les éléments fondamentaux, tandis que les développeurs GNOME peuvent promouvoir plus rapidement et de manière plus flexible les modifications de design nécessaires, sans affecter GTK lui-même.
La bibliothèque comprend des widgets standards couvrant divers éléments d'interface, tels que des listes, des panneaux, des zones de texte, des boutons, des onglets, des formulaires de recherche, des boîtes de dialogue, etc. Les widgets proposés permettent de créer des interfaces polyvalentes qui fonctionnent harmonieusement tant sur les grands écrans des PC et ordinateurs portables que sur les petits écrans tactiles des smartphones. L'interface des applications s'adapte dynamiquement en fonction de la taille de l'écran et des dispositifs d'entrée disponibles. La bibliothèque inclut également un ensemble de styles Adwaita, alignant l'apparence avec les recommandations GNOME, sans nécessiter d'adaptation manuelle.
Le changement principal dans libadwaita 1.5 est la refonte des widgets réactifs pour créer des dialogues qui s'adaptent à la taille de l'espace visible. Contrairement aux dialogues traditionnels qui s'affichent dans des fenêtres séparées, les nouveaux dialogues sont formés côté client, dessinés à l'intérieur des fenêtres existantes et ne peuvent pas dépasser les limites de la fenêtre parent. Cette approche simplifie la création de dialogues universels, compatibles avec les interfaces des systèmes mobiles et de bureau, tout en offrant des possibilités supplémentaires de gestion des dialogues (par exemple, il n'est pas nécessaire de suivre le dépassement des limites de la fenêtre, il est possible de choisir le comportement concernant les boutons de fermeture, un déploiement automatique en plein écran est assuré dans les versions mobiles des applications, et le style de la fenêtre actuelle, et non celui du système, est pris en compte lors de l'assombrissement du dialogue).
Il est prévu de mettre en œuvre une autre variante de ces dialogues, attachée non pas aux fenêtres, mais aux onglets à l'intérieur de la fenêtre, cela peut être demandé dans des applications telles que les navigateurs, afin que les dialogues liés aux onglets ne masquent pas la fenêtre principale lors du changement entre les onglets.
Pour les appareils mobiles, un support a été mis en place pour le placement de dialogues sous forme de feuilles fixes en bas de l'écran (bottom sheets), plutôt que sous forme de feuilles centrées. Les dialogues fixés en bas permettent d'éviter aux utilisateurs la confusion liée à la fermeture des fenêtres : dans ces dialogues, une partie de la fenêtre parent reste visible et les boutons de fermeture de la fenêtre parent et du dialogue lui-même sont clairement séparés, ce qui les rend maintenant difficiles à confondre.
La gestion des nouveaux dialogues se fait à l'aide de la classe AdwDialog, dont l'utilisation dans la plupart des situations ressemble à celle de la classe GtkWindow, les différences se limitant aux opérations d'affichage et de fermeture. Par exemple, la propriété «:transient-for» a été remplacée par un paramètre dans la fonction adw_dialog_present(), un nouveau signal «::close-attempt» a été ajouté, et la gestion du paramètre «:can-close» a été modifiée. Au lieu des classes AdwPreferencesWindow, AdwAboutWindow et AdwMessageDialog, il est proposé d'utiliser les classes AdwPreferencesDialog, AdwAboutDialog et AdwAlertDialog pour les nouveaux dialogues.
Les dialogues qui n'ont pas de fenêtre parente continueront d'être traités sous forme de fenêtres séparées. De même, les dialogues dont les fenêtres parentes ne peuvent pas être utilisées pour placer des dialogues, par exemple, s'ils ne peuvent pas être redimensionnés ou n'ont pas les classes AdwWindow et AdwApplicationWindow, fonctionneront également comme des fenêtres.
Modifications non liées à la refonte des dialogues dans Libadwaita 1.5 :
- La classe AdwEntryRow a ajouté la propriété «:text-length» pour limiter la taille du texte dans le champ de saisie.
- La classe AdwMessageDialog a ajouté la méthode remove_response().
- La classe AdwBreakpointBin, qui permet de modifier l'interface utilisateur de manière arbitraire en fonction de la taille de la fenêtre, a ajouté la possibilité de supprimer les points d'arrêt par programmation.
- La classe AdwSwipeTracker a ajouté le drapeau «:allow-window-handle», permettant de faire défiler au-dessus de la barre supérieure (utilisé dans les feuilles fixées au bas).
- La luminosité des couleurs utilisées pour l'assombrissement des fenêtres en mode sombre a été augmentée.
Source : opennet.ru
